Skip navigation
All Places > Products > RSA Identity Governance & Lifecycle > Blog > Author: Sean Miller
1 2 Previous Next

RSA Identity Governance & Lifecycle

24 Posts authored by: Sean Miller Employee

In earlier releases of RSA Identity Governance and Lifecycle, a feature to limit the expiration date chosen during rule remediation was made available under the Rules->Configuration menu.  Similar functionality has been introduced in the RSA Identity Governance and Lifecycle 7.2 release for reviews so review administrators can set the maximum number of days access can be maintained with an expiration date.  The settings can be changed under the Reviews->Configuration and Rules->Configuration menus.  The same setting is exposed in both places allowing administrators to specify the default number of days for exception access and also the maximum number of days.

 

 

Once configured, reviewers will be limited in the calendar control available to select expiration dates.  The default date will be selected based on the configuration and the user interface will not allow selections beyond the maximum number of days.

 

For additional information on this update – please check out this additional context:

In earlier release of RSA Identity Governance and LIfecycle, the Generic REST connector was introduced and is being used by many customers.  In the RSA Identity Governance and Lifecycle 7.2 release, we have introduced the matching connectors to allow you to collect entitlements, accounts, and identities from endpoints using REST API calls.  REST is becoming a standard way to interact with systems returning data in a well defined structure (JSON).  One of the key advantages is that if endpoints change implementations, you don't need an entirely new collector but instead simply adjust the REST API calls configured slightly.

 

To get started, create a new collector and select Generic REST as the data source type:

 

 

The following video dives deeper into what to consider when creating a collector and how to handle things like pagination, authentication, and how to debug the configuration.  A REST client like Postman is recommended to determine the right apis to call and how to parse the responses:

In the RSA Identity Governance and Lifecycle 7.2 release, we have introduced a new component that can be used on dashboards to display a single value "fact".  Dashboard Facts are a convenient way to provide high level information on a dashboard with click through support to dive into the details.  Combined with other dashboard components you can build very powerful dashboards targeted to specific users or roles.

 

To create a dashboard fact, you will need to decide on the fact you want to show.  For example, maybe I want to know how many applications have been onboarded into RSA Identity Governance and Lifecycle.  Dashboard facts can appear on any type of dashboard (Welcome, Object, or Topic level).  Along with the fact you will want some visualizations like a name, a colour for the fact, and some descriptive text to explain why anyone cares about the fact (or to give the context for the fact).  When creating a fact, the most important thing to keep in mind is what is the fact meant to convey.  For example, if I show a number of 100 is that a good thing or a bad thing someone may want to drill into more.  For this reason, keep your facts concise.  In addition to the fact itself, you can configure an url that allows the fact to be clicked on to get more details.  This is especially useful to provide a high level dashboard that links to a lot more content like a report or a detail screen within the product.

 

 

It is highly recommended you start with thinking about the fact you want to present and is there an efficient way to get the value to display.  Performance is the key as the query will be run everytime the dashboard is displayed.  RSA recommends using values that are not calculated at runtime.  For example, use counts for objects that are gathered daily and stored in the public view PV_TELEMETRY_DATA  rather than a query that does an actual count every time the query is executed.

 

To showcase this new feature and help system administrators, the 7.2 release includes a new dashboard available out of the box called 'System Admin' Dashboard.  Facts like the number of admin errors are shown on this dashboard with click through support to take the end user to the actual admin errors.

 

For additional information on this update – please check out this additional context:

Two new review analysis have been introduced in the RSA Identity Governance and Lifecycle 7.2 release:

 

 

 

 Never Reviewed

This new category finds any access that has not been reviewed by any reviewer in any review.  This helps reviewers to identify items that have never been reviewed in their list and take appropriate actions.  Other review items will likely have similar review actions to previous reviews unless a user's role or status has changed.

 

 Expiring Soon

Exceptional access given for access raised as a violation will be flagged by this category if the expiration date is within 30 days (default) from the time of the review generation.  The default value can be overridden by navigating to Admin->System->Settings.  This allows reviewers to review the access and make a decision before the access expires and goes through another round of remediation.

 

These new categories can be configured from the Analysis & Guidance page of the review definition along with the other existing categories:

 

For additional information on this update – please check out this additional context:

Sean Miller

New Feature: IMAP Support

Posted by Sean Miller Employee Feb 11, 2020

Email protocols have evolved and to remain modern and provide secure solutions theRSA Identity Governance and Lifecycle 7.2 release now includes IMAP/IMAPS as a supported protocol for receiving inbound emails.  This can be configured on the Admin->Email->Settings page.

 

 

IMAP is recommended to use for the inbound server protocol rather than POP3 and many organizations are now requiring the use of this protocol.

In the RSA Identity Governance and Lifecycle 7.2 release the user interface is cleaner, more consistent, and provides a more cohesive experience.  We have moved to a style guide based reusable component framework.

 

This release includes redesigned UI components and features such as:

  • Dialogs
  • Buttons
  • Tables
  • Charts
  • Links
  • Card based component layout
  • New icon set for high resolution displays

 

Color Palette and Fonts

A palette of named colors for styling components is used now rather than hex codes used in multiple places.  This means one css file controls all color palettes making it consistent across all the UI components in the application.  

The default font has now been set to "Open Sans" and a consistent font sized used based on the context (Title: 20px, Heading: 16px, SubHeading: 12px ....).


Buttons

Buttons are now shown as primary, secondary, and tertiary buttons to help highlight the primary action, secondary action, and other actions that a user might be interested in.  Some buttons are now associated with action icons providing a visual cue to help with accessibility.

 

Icons

A new icon set for higher resolution has been provided.  This improves the scalability leading to faster performance and browser loading, avoids pixelation on larger displays, and avoids image redundancy.

 

Similarly, loading icons have been replaced by a standard spinner icon that is more scalable.

 

Notification Panel

The notification panel accessible from the top right of the main menu now has a cleaner user interface incorporating card based component layout with notifications grouped by date.

 

Progress Bar

Progress bards have been redesigned to look cleaner and render better in browsers.  Several browsers experienced clipping issues and the component was not performant.

 

Dialogs

The layout of dialogs has been changed so the header background color to a primary color (blue), new button design is used for primary and secondary actions, and links are highlighted in blue. 

 

Tabs and Breadcrumbs

Tabs are now shown as a minimalist component where the selected tab is denoted by an underline.  Earlier iterations were much busier, required rendering time in browsers, and proved to be distracting in user interaction testing.

The title of the page is shown now above the breadcrumb, highlighted in blue.  The breadcrumb shows a detailed path and allows the user to navigate to any page present in the path (earlier versions just allowed navigation back to the home page).

 

Tables

Tables have been redesigned with a modern them and includes a redesigned pagination component that is consistent across the application.  The go to page functionality has been separated out by aligning it to the bottom right of the table.

Table filtering has changed so the active filter is blue and other available filters are white.  Disabled filters are shown with a gray background.  Grouping and searching fields have also been made more consistent and clean in this release.

 

Links

Links are not represented in a blue color and appear red when hovered over with an underlined font.

 

Charts

Charts now have a modern theme and layout with improved animations.  A standard color palette is used and new options have been added to download charts in the desired user format.

 

Form Elements

The active field is now more evident in forms using a blue border to highlight text box and text area controls.

 

What's New Page

The what's new page has been redesigned to showcase key features in the top card based slider.  Other features are also shown on this page in standard cards below the slider.  The features here are controlled by entries in the strings.properties and additional text/highlights can be added in customerstrings.properties for customer environment's.

 

These are just some of the exciting changes we have made in the user interface this release.

The topic of 'System Data and Diagnostics' is not new news.  We announced these capabilities in 7.1.1 in this blog.  However, in the RSA Identity Governance and Lifecycle 7.2 release we have added additional data points and functionality.

 

It is important to understand the 'System Data and Diagnostics' feature is made up of two key parts:

  • Gathering
  • Sharing

 

All configuration for this feature is done on the Admin->Diagnostics->System Data and Diagnostics page.

 

 

Gathering

This is a scheduled task that runs daily to calculate and store off data points.  Once stored, these data points can queried using the public view PV_TELEMETRY_DATA.  These are extremely useful to show the state of the system, show trends over time (like application onboarding), show return on investment (decreasing trend of rule violations), and highlight gaps (number of orphaned accounts).

 

A key value add of having the gathered data is that it is static data perfect for reports and dashboards instead of real time potentially expensive count queries.

 

Data is gathered from yesterday and beyond to avoid incomplete data for today since the time the gathering runs versus collections and other activities may vary

Sharing

In additional to gathering the data points, it is recommended you configure the system to also share this data with RSA.  This document describes in detail what is collected and shared here.  It is important to note that there is no personal data shared like user information and with the exception of the customer name, there is no other identifying information gathered.  By providing the data to RSA, this helps RSA understand how customers are using the product and where we should be investing, what areas are not being used which helps us make deprecation decisions, and understand the size of deployments and identify opportunities where RSA can have conversations to help our customers.  Lastly, this also helps RSA identify key customers to participate in beta programs or design partnering based on their use of the product.

 

To share the data, the IGL server needs to be able to access the web site - https://cms.netwitness.com/telemetry

 

For additional information on this update – please check out this additional context:

In the RSA Identity Governance and Lifecycle 7.2 release, we have enhanced the unauthorized change detection feature processing:

  • Filter by Accounts
  • Filter by Users
  • Filter by Groups
  • Detect Unauthorized Missing Access

 

Filter By (Accounts, Users, Groups)

When creating a new unauthorized change detection (UCD) rule, the rule will continue to apply to all accounts in the system by default.  To have the rule take action for specific accounts or exclude specific accounts click on the “All”.

Any UCD rule existing prior to this version will default to ALL accounts as that is the equivalent functionality in prior releases.  

Clicking on the “All” will produce a pop-up which is our standard filter screen where you can limit the accounts.

 

 

Detect Unauthorized Missing Access

The Unauthorized Change Detection rule previously was only capable of detecting any new access that was collected for a user which was not authorized.  This enhancement will detect when the selected access is removed from a collection for a user which was not authorized.

As seen in the UI there are two new check boxes.  The first ‘Detect New Access’ represents the old functionality and ‘Detect Missing Access’ represents the new functionality.  Any new rule will default so that detect missing access DISABLED as that is consistent with the default action of the rule in prior versions.  You must go and enable this check box by choice.

Any UCD rule that exists in a prior version will be migrated so that the detect missing access is also disabled keeping the execution of the rule consistent with prior versions.

 

 

For additional information on this update – please check out this additional context:

Sean Miller

New Feature: User Pictures

Posted by Sean Miller Employee Feb 11, 2020

User pictures have been introduced in the RSA Identity Governance and Lifecycle 7.2 release to help various RSA Identity and Governance actors make decisions when reviewing, approving, or remediating user's access.  An image can now be associated with a user and is displayed on the user detail screen and the user information popups throughout the product.  The image is also shown for the active user in the menu bar when logged in.

 

 

User pictures can be managed a few different ways be default:

  • Self - A user can modify their image on the user's detail screen
  • Direct reports - A supervisor can set the image for any user's they can edit.  Usually this equates to their direct reports but this can be controlled through security context configurations.
  • Administrator - Pictures can be directly uploaded through the Admin->User Interface->Files (Users) page.  The filename must match the userid of a user before it will be used.
  • Web Services - Pictures can also be uploaded using the setUserImage web service.  This web service requires a token for a user that can modify the specified user.  This is a useful way to manage images in bulk leveraging curl calls.  There is also a getUserImage web service that can be used to access the picture for a specific user

 

The security for who can edit the images can be controlled by granting the User:Edit Image, User:Edit Self Image, and User:Edit All Image entitlements to the desired users.

 

For additional information on this update – please check out this additional context:

In the recent RSA Identity Governance and Lifecycle 7.1 release, the user interface can customized to better brand the product for the customer's environment.  One new key customization available is the background image displayed when user's are on the login screen.  The file must be a JPEG file that is called login-background.jpg.  The file should be uploaded to the Admin→User Interface→Files page under the images section.  When new users login, they will be shown a customized login screen like the following:

Things to consider when customizing this:

  • The image should be a decent resolution so it renders on various client screen resolutions
  • The file size should not exceed 10MB so it doesnt impact the speed to load the screen the first time too much
  • The uploaded image is audited as part of the events found under Admin->System→Audit

 

Included in this blog is a set of background images (see attachments) to try out.  Rename the image to login-background.jpg and upload.  The image will be shown the next time you login to the product.

Sean Miller

New Feature: Web Services

Posted by Sean Miller Employee Mar 19, 2019

In the recent RSA Identity Governance and Lifecycle 7.1.1 Service Pack Release we have added some new web services.  In previous releases you could use the findApprovals, getApprovalDetails, and performApproval web services to interact with approvals.  In this release the following web services have been introduced to interact with any type of work item including approvals:

 

  • getWorkItemsForUser
  • getWorkItemDetails
  • performWorkItem

 

The getWorkItemsForUser web service returns high level details for the work items including the work item IDs.  The getWorkItemDetails takes a work item ID and returns more details including what actions can be taken.  The actions that are returned are based on the transitions modeled in the workflow.  The performWorkItem web service is used to complete the work item using the provided action and comment.

The approval-specific web services will be deprecated in a future release.  Any implementations based on this should be updated to use the more generic work item web services.

      

 

Lastly, the new web service findReviews has be introduced in this release.  This allows you to search for reviews by name or other search criteria.  The web service returns details about the reviews based on the requested columns.  In particular, the review ID is returned which is needed for other calls like getReviewStatus, refreshReview, setReviewState, and updateUnreviewedItems.

Sean Miller

Security Context

Posted by Sean Miller Employee Nov 21, 2018

This is for advanced users.  While security contexts can help control who can do what in the product, it can adversely affect performance if you have a lot of rules or the scope filters are very heavy to evaluate.  These rules must be evaluated on every user login.

Custom security context files can be used to define your own security rules and/or overload security rules provided in the shipping product.  The key to identifying if you are adding new privileges or modifying existing ones is based on matching the secure object type, name, and action.  If those match an existing entry, then you are overloading an existing privilege.

 

Custom Security Context

To customize the security context, you should:

  1. Do NOT modify the default file inside the aveksa.ear
    Modifying the security context file inside the aveksa.ear is not supported and you will lose your changes on upgrades, moving to other systems, or within a cluster.  By following the steps below you will keep your changes, they will be included in upgrades, and all nodes involved will see the changes.
  2. Take a copy of it to your PC (to use for reference later) so you have the header format and you can see existing entries.
  3. Create a new SecurityContext.csv file with the Header and a line for each privilege you want to add or modify or delete.
  4. Save and upload the custom security file to the UI under Admin > User Interface > Files > Security.

New Privilege

A new privilege is defined when it has a unique secure object type, name, and action.  The product has an internal fixed list of security object types and actions it supports so adding your own won't have an effect (only introduce unique names).

 

If the following privilege is defined, then I might introduce a similar privilege with a different name.  This has the effect of adding to the existing security privileges for the secure object and action:

 

SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER

Application,Business Owner,Manage,,scope,,t_applications,business_owner=${id} and resource_type='A' and is_deleted='FALSE'

Application,Custom Business Owner,Manage,,scope,,t_applications,cas1=${id} and resource_type='A' and is_deleted='FALSE'

 

In the example above, we defined a new privilege that is going to look in the custom attribute CAS1 to determine if the logged in user should have the Application:Manage privilege.  I named this new privilege 'Custom Business Owner'.

 

To use the new privilege, upload the custom security context file using the 'Custom Security Context' section above.

 

Modifying Default Privilege

To modify an existing privilege, following the steps in the 'Custom Security Context' section above. Find the line of the existing privilege. In this example:

 

Change Request,Affected,View,scope,,,t_av_change_requests,scope.id in (selectchange_requests_id from t_av_change_request_details where affected_user_id=${id})

 

Modify the scope filter for the privilege and upload the custom security context file on the UI under Admin > User Interface > Files > Security.

 

Disabling Default Privileges

Should you want to disable an existing privilege, then you should follow the exact same steps as in the modifying default privilege, but provide a scope filter that is never true (For example: 1=0).

 

SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER

Change Request,Affected,View,scope,,,t_av_change_requests,1=0

 

Many people have incorrectly tried to modify the default security context file instead removing the physical entry all together.

This posting is based on functionality as of 7.1.0 P04 and 7.0.2 P10

We have all been driving our car and at some point a light comes on the dashboard.  Sometimes it is a simple orange light like the windshield fluid.  We should top that up but I can keep driving without harm likely (unless I can no longer see the road).  The dashboard might similarly show me an orange check engine light.  This usually means you need to get your car into the shop but it isn't an immediate concern.  Alternatively, the same light might show red telling you a serious problem has occurred in your engine.  You need to stop driving now.  In the recent  RSA Identity Governance and Lifecycle 7.1 release, we have introduced a similar concept focusing on workflow system status.

The Admin->Workflow→Monitoring page will show you a real time view of the workflow system status.  This includes graphs for how hard it is working (Number of Items Serviced), if anything is backing up (Queue Size), and system status indicators.  The status indicators only show if there is an issue. Not only do the status indicators surface that there is a problem, they generally have a means to resolve the problem or at least get more details.  A status indicator will show a hand cursor if you can click it for more information to resolve the issue.  In addition to the visual indicators,  the system will send out admin errors with the appropriate status and information.  The administrators can configure Notification rules to email these events to the appropriate administrator.   

 

The system is configured to monitor the following conditions and surface workflow status indicators.

Verification (Count)

This status indicator determines how many changes are pending verification that are older than one month and less than 12 months.

Thresholds

  1. Warning - 100 changes
  2. Error - 500 changes
  3. Critical - 1000 changes

Resolution

This status indicator allows you to click through to a screen that shows the changes that we are trying to verify.  The verifications will be dealt with by future collections or an administrator can choose to cancel a change here to remove the verification.

Verification (Age)

This status indicator determines if there are any changes pending verification that are older than n months

Thresholds

  1. Warning - no warning by default
  2. Error - There are changes older than 6 months that havent been verified
  3. Critical - There are changes older than 12 months that havent been verified

Resolution

This status indicator allows you to click through to a screen that shows the changes that we are trying to verify.  The verifications will be dealt with by future collections or an administrator can choose to cancel a change here to remove the verification.

Queue Backup

This is a series of status indicator (one for each priority queue type) that will show if work 

Thresholds

  1. Warning - 1000 ms by default
  2. Error -      2*60*1000 ms by default
  3. Critical -  4*60*1000 ms by default

Stalled Workflows

This status indicator determines if there are any workflows marked as stalled.

Thresholds

  1. Warning - 0
  2. Error - 50
  3. Critical - 100

Workflows should not ever be marked as stalled.  So even one is being considered a warning.

Resolution

This status indicator allows you to click through to see the stalled workflow jobs.   In general, a stalled workflow needs to be examined more closely to see if there is some flaw in the business logic.  A stalled workflow indicates something took longer than expected.  From this screen you can also evaluate the workflow(s) to see if they can proceed. 

Database Connections

Thresholds

 

  1. Critical - Any exception thrown by the workflow engine that it can no longer communicate with the database

Resolution

Clicking this status indicator icon opens up dialog where an administrator can check if the workflow engine can communicate with the database. If the connection is successful, the status indicator is cleared and an admin error is logged for change of status.

For more information on this feature – please check out Workflow Priority Queues 

Sean Miller

Workflow Priority Queues

Posted by Sean Miller Employee Feb 19, 2018

In the recent  RSA Identity Governance and Lifecycle 7.1 release, we have introduced priority queues in the workflow engine.  These are not exposed to end users but are designed to provide more throughput in processing workflows.  In particular, if a larger request is being processed, some other types of requests can still get through if they are deemed important enough rather than waiting in line.  In the past, the workflow engine processed things in a first come first served model.

in addition to help improve throughput, the priority queues will also help with isolating longer running work and identify potential problems.  For example, a very large role change that is committed can generate a number of indirect entitlement changes for all the role members.  These are now processed using a different priority queue than normal changes flowing through the system from explicit requests end users are making.  Similarly, changes related to SQL Select, SQL Execute, and Java nodes are processed by a different priority queue.  This will help workflow developers and administrators identify if there are long running custom logic that needs closer inspection.

 

The following priority queues are defined now:

  • Normal (Default) - explicit changes flow through this queue
  • Urgent - Requests of that represent user terminations or password resets are handled by this queue
  • Role - Requests that are role related (usually containing indirect entitlement changes) are handled by this queue
  • Custom nodes - Logic run as part of SQL Select, SQL Execute, and Java nodes are handled by this queue

 

The Admin->Workflow→Monitoring screen provides a real time view of what is going on in the workflow engine.  The priority queues are shown in this interface so you can see how each queue is performing and where there may be bottlenecks that need closer inspection.

For more information on this feature – please check out this additional content. 

Workflow Priority Queues 

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.

Filter Blog

By date: By tag: