Skip navigation
All Places > Products > RSA Identity Governance & Lifecycle > Blog > 2017 > March > 29

With a focus on helping organizations achieve business agility – we are proud to announce an improvement to request forms and workflows in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release 

 

Prior to this release, all request forms were processed using the request workflow that is configured on the Requests->Workflows->Overview screen for the explicit request source.  This has led to many customer workflows where business decision logic is needed to route the request differently based on the source.  This can help separate the business logic for a request form into it's own specific workflow.  Although many request forms should continue to go through the normal request workflow, this feature can help isolate your business logic for a specific form from all other workflows.

 

To configure this feature, edit a request workflow and select the appropriate request workflow using the picker shown beside the Request Workflow label:

 

Any requests that are generated using this request form are then processed using the configured request workflow.

With a focus on helping organizations achieve business agility – we are proud to announce the release improvements to account templates in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release With this new release, an account template can leverage the power of naming policies directly.  In earlier releases, you could only use naming policies through a request form.  This meant that any request created from a source other than a request form would need special logic to create accounts.

 

With 7.0.2, whenever an account needs to be created the naming policy can be used to generate a unique name.  This is done by associating a naming policy right on the account template object:

 

Once associated, you can refer to the value of the naming policy like any other variable.  In this example, the calculated value is mapped directly to the name of the account with no additions:

 

Consider using this feature and remove the custom business logic from the workflow to calculate the name of the account to create.

Ever wondered what the workflow engine is doing?  While you can see at a high level the phase your request is in, there are times where it is useful to ensure the workflow engine is running and how busy it is.

 

We are proud to announce the release of the workflow monitoring feature in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release .  

 

This feature is located on the Monitoring screen found under the Admin->Workflow menu.  This screen has a few purposes:

  • List the name and state of all the configured queues associated with the workflow engine
  • Show how hard the workflow engine is work (Number of Items Serviced)
  • Show how much work there is to do still (Queue Size)

 

While I can's tell exactly where my change request might be in a long line of work to do, this screen will help us understand that things are still moving and how much volume there is.  This screen will update the metrics every minute shows a real time glimpse into the workflow engine with scrolling graphs. 

 

NOTE: This information is not written to any database tables for historical review.  The screen is purely meant for real time inspections of the system.

Have you ever gone to add a user to a role and been overwelmed by all the indirect entitlements the user receives because of the role?  Many approvers are as well.

 

With a focus on helping organizations achieve business agility – we are proud to announce the release of the simplified approval improvement in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release .  

 

Most approvers are not spending all day in the RSA Identity Governance and Lifecycle product and they are being involved in the process for business reasons.  In this scenario, 99% of the time we probably are asking an approver the question: Should this user be a <role name>?  For example, if someone joins my team, I am likely being asked if they should be a developer and my job is to approve or reject that.  What it means to be a developer is an entirely different problem likely maintained by a very different process.  For this reason, we have added a new setting to approval workflows and changed the default for the out of the box approval workflows and any new approval workflows that are created to not include indirect entitlements by default.  Existing customer approval workflows are not touched. 

 

You may want to reevaluate your approval process though and decide if you really want your approvers worrying about indirects either.  Do you want them focused on the simple question: Should this user be a developer or do you want them really approving the one hundred other entitlements the user will receive because they are a developer?

In earlier releases all attributes were visible to users.  This made sense in some use cases but this quickly became a general security concern where only privileged users should be able to see the majority of the attributes.  In the first iteration of this feature, RSA chose the attributes that were shown for user objects.  While this solved the security concern, there were several customer use cases that were not met by this functionality. 

 

With a focus on helping organizations achieve business agility by limiting who can see what attributes – we are proud to announce the release of the public versus private attributes feature in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release System administrators can use the public versus private attribute feature to configure what attributes are public.  Only public attributes are visible to non-privileged user.

 

For example, if I am a reviewer for an application, I may be able to see who has access to my application.  While it is important to have some details about the user to decide if the access should be maintained or revoked, it does not make sense for me to see all attributes about the user.  The user object may include some more sensitive attributes that administrators have decided to keep private.  By default, a very minimal set of user attributes are marked as public.

With a focus on helping organizations achieve business agility – we are proud to announce the release of web service features in the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release With this new release, we have added some additional web services and also enhanced some existing web services.  Documentation on all the web services available can be found on the Admin->Web Services page of the RSA Identity Governance and Lifecycle console.

 

Single Sign On

The loginUser web service has been enhanced to accept an authentication source.  This can be used in conjuction with credentials or you can specify the authentication source by itself and the authentication source then relies on artifacts already present in the request for authentication.  For example, you might specify a configured SSO user header authentication source.  The web service would use the authentication source to validate the right artifacts are there before returning a token.  The token can then be used for subsequent web service calls.

 

Process Rule

A new web service to run a specific rule or all rules is now available.  The call requires appropriate security privileges as documented on the web service page.

 

Update Review Items

updateReviewItems is a new web service that can be used to update review items outside of RSA Identity Governance and Lifecycle's review user interface.  This may be used for use cases where a reviewer is reacting to an email received for example or some form of offline/out of band review where decisions are sent back to RSA Identity Governance and Lifecycle using the web service.

 

Create Change Request

The createChangeRequest web service has been enhanced to support additional operations:

* Terminate user

* Mapping users to accounts

* Unmap users from accounts

All of these operations are described and examples provided on the Admin->Web Services page.  A successful call will result in a change request that can then be approved and fulfilled through RSA Identity Governance and Lifecycle.

The mapping and unmapping from accounts operations are demonstrated here.

Have you ever wanted to go on vacation and not be bothered for escalated approvals, activities, and reviews?  Well now you can with the latest release - RSA Announces the Availability of the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release.    We have added a new feature to enable a user or manager to set their availability as gone fishin’ out of office and select a delegate to act on their behalf. 

 

During the out of office period the delegate will see any approvals, activities or reviews that would have normally been
assigned to the user that is currently out of office.  The delegate completes the work as if it was their own and the audit history will capture the fact the user acted as a delegate.  Once the out of office period ends - any unfinished delegated tasks will revert back to the original owner. 

 

Administrators can limit who can be selected as a delegate, change the default out of office workflow and see a clear audit trail of activity. 

 

Please check out additional content on the new feature

 

Introduction to Out of Office Task Delegation 

Out of Office Task Delegation - Delegate Experience 

Out of Office Task Delegation: Forms and Workflows 

 

Achieving Business Agility with RSA Identity Governance and Lifecycle.

Identity has emerged as the most consequential attack vector for threat actors, but risk is not evenly distributed across all user populations.  Privileged users and applications potentially pose more risk to the organization than non-privileged users.  Unauthorized access to privileged user credentials enables faster advance of a cyber-attack and the higher probability of a costly data breach or devastating disruption of service. 

 

To mitigate the security and compliance risks associated with all users, including privileged users, organizations must have control and visibility of all user access and their entitlements.     We are proud to release support for Lieberman Enterprise Random Password ManagerTM (ERPM) collection and provisioning in the latest release - RSA Announces the Availability of the RSA Identity Governance and Lifecycle 7.0.2 Service Pack ReleaseThe interoperability of Lieberman ERPM and RSA Identity Governance and Lifecycle enables organizations to gain a unified, policy-driven identity and access governance across all users. Once deployed, the interoperable solution effectively arms organizations with the information they need to quickly identify and respond to security risks involving the organization’s most powerful identities – privileged users.

 

Solution Benefits:

  • Provides enhanced visibility and control of privileged accounts and access data directly from RSA Identity Governance and Lifecycle.
  • Unifies account provisioning processes for privileged and non-privileged users.
  • Ensures privileged users are granted appropriate access permissions based on similar privileged users’ attributes (e.g. roles, job functions), and in accordance with the organization’s access policy. Allows the line of business to make access decisions
  • Reduces the attack surface and enhances regulatory compliance by limiting access privileges and deactivating stale/orphan privileged accounts.
  • Streamlines governance and compliance processes by generating reports and auditing all identities and access permissions directly from RSA Identity Governance and Lifecycle.

 

Please check out additional content on the new feature

 

Collection and Provisioning with Lieberman ERPM 

RSA Identity Governance and Lifecycle - Lieberman Software Rapid Enterprise Defense Identity Management 

 

Reduce Identity Risk with RSA Identity Governance and Lifecycle.

 

Identity has become the most consequential cyber-attack vector.  According to the 2016 Verizon Data Breach Investigations Report, 63% of confirmed breaches involved the use of weak or stolen credentials. Attacks may start with simple account compromise or control of orphaned accounts but quickly escalate to the most prized credentials—those of privileged users.   

 

With a focus on helping organizations reduce identity risk – we are proud to announce the release of the password vault
feature in the latest release - RSA Announces the Availability of the RSA Identity Governance and Lifecycle 7.0.2 Service Pack Release
The password vault feature will allow RSA Identity Governance and Lifecycle to retrieve and rotate privileged credentials from CyberArk Application Identity ManagerTM (AIM). 

 

The password vault interoperability supports the following endpoints:

 

Please check out additional content on the new feature

 

Configure Password Vault  

Password Vault: Configure Active Directory Connector 

Password Vault: Password Rollover 

 

Reduce Identity Risk with RSA Identity Governance and Lifecycle

Identity has become the most consequential cyber-attack vector.  According to the 2016 Verizon Data Breach Investigations Report, 63% of confirmed breaches involved the use of weak or stolen credentials. Attacks may start with simple account compromise or control of orphaned accounts but quickly escalate to the most prized credentials—those of privileged users.  

 

With a focus on helping organizations reduce identity risk - our upcoming v7.0.2 release includes interoperability between Lieberman ERPM and RSA Identity Governance and Lifecycle to enable organizations to gain a unified, policy-driven identity and access governance across all users. Once deployed, the combined solution effectively arms organizations with the information they need to quickly identify and respond to security risks involving the organization’s most powerful identities – privileged users.

 

 

Lieberman Software Announces Interoperability with RSA® Identity Governance and Lifecycle - Liebsoft