Skip navigation
All People > Andrew Nguyen > Andrew Nguyen's Tech Tips > 2018 > February
2018

Improve loading of users current permissions

Improves the Current access rights loading performance (when user has many Provisioning Roles for example).

After deploying this fix you will need to make these changes in the ‘Sigma – Current Access’ admin task in IDM:

  1. Open the task’s ‘Tabs’ tab and remove the ‘Provisioning Roles’ and ‘Provisioing Roles Indirect’ tabs from the list.
  2. Edit the task’s Profile tab screen, ‘Sigma User Profile’:

Add a new Screen Logical Attribute. Name it “|provRoles|" and check the ‘Multi-valued’ checkbox.

 

 

Add the following code to the screen’s "Initialization Javascript" section:


function init(ScreenContext){

importClass(Packages.java.util.HashSet);

importClass(Packages.com.netegrity.llsdk6.imsimpl.securityengine.ProvisioningSecurityEngine);

                var iamsession = null;

 

                var results = new java.util.HashSet();

                var user = ScreenContext.getUser();

 

                try {

                iamsession = ProvisioningSecurityEngine.getIAMSession(user);

                var iamdomain = iamsession.getRootDomain();

                var iamUser = iamdomain.getUser(ProvisioningSecurityEngine.getProvisioningFriendlyName(user));

                if (iamUser != null) {

               var roleHandleList = iamUser.property("roleHandles");

                                                var iter = roleHandleList.iterator();

                                                while (iter.hasNext()) {

                                                                var role = iter.next();

               results.add(role.getBaseName());

                                                }

               }

                } catch (e) {

                                ScreenContext.logErrorMessage("##################### Failed to get prov roles: " + e, false);

                } finally {

                    if (iamsession != null)

                        iamsession.close();

                }

 

var vector = new java.util.Vector();

vector.addAll(results);

ScreenContext.setFieldMultiValue("|provRoles|",vector);

}

 

 

  1. Save the changes and restart the connector in Identity Portal.

The issue was in the way the CA Identity Manager displays error information after a user account has been locked out, which allowed attackers to brute-force credentials and use them after the account is no longer locked.

The system would display 'Error: Username and password do not match' when an incorrect username/password combination was used, which of course, makes sense. However, when correct credentials are used for a locked account, the user is redirected to /iam/im/pub/cui7/index.jsp?SMAUTHREASON=24&task.tag=passwordServices and the error message is: 'Error: You cannot access your account because you have exceeded the limit of login attempts.

 

The expected functionality is:
* Create IM password policy which specifies that user must be disabled after 3 successive failed login attempts
* Create a user (say) user1 with the password ‘test’
* Log on successfully
* Log on 3 times with the password ‘testxxxx’
* Log on a 4th time with the password ‘testxxx’. You should get a message that you are now disabled
* Log on a 5th time with the correct password ‘test’. You should get a message that you are now disabled

These steps noted previously was to test if the vulnerability existed in your system or not.


This functionality is handled by SSO Password Services, why did CA issue a patch for IDM?

Identity Manager and SSO handles authentication differently. If SSO was not integrated the above vulnerability would happen. IF SSO is integrated with Identity Manager, SSO handles all the authentication and would not be affected.

To make sure if this makes sense:

Authentication process:

With SSO-IDM

Login with SSO username and password.-> Authentication approves -> Session is sent to IDM

Without SSO,

Login with IDM username and password -> Authentication approves -> session is sent to IDM

Hopefully you can see how the authentication is handled differently. With SSO when authentication fails it would send a message to SSO about the failed login versus when the authentication fails with IDM it would send a message to IDM.