Extending IG as a complete UMA-RS

Both AM and IG support UMA 1.0.1 where AM acts as UMA Authorization Server (AS) and IG as UMA Resource Server (RS).  

Currently there are some limitations in UMA support in IG, one of the most important is: PAT is stored in IG memory and is not persisted and if IG is restarted then the resource owner must perform the entire share process again.

Note: This post is based on UMA 1.0.1 (Support for UMA 1.0 and UMA 1.0.1 will be removed in a future version of ForgeRock Access Management) 

Solution

Versions used for this implementation: IG 5, AM 5.1 and DS 5

We can overcome some of these limitations by extending IG-UMA filter:

Some of the features of this extension:

• Realm support 
• Extend IG-UMA REST endpoint: Authentication using PAT 
• User friendly UMA Resource name 
• Persisting UMA ResourceSet id and PAT in DS/OpenDJ: 

UMA Flows

• Alice share UMA resource

• Bob access UMA resource

Deploy

• Pre-requisites 
• DS configurations 
• IG configurations

Testing

• IG-UMA REST endpoints
• UMA use-case testing 

See Also

Get code

Unlock user account using OpenAM Forgot Password flow

OpenAM provides "Account Lockout" functionality which can be used to configure various lockout parameters such as failure count, lockout interval etc. 
Note that OpenDJ also provides Account Lockout functionality, this article is based on OpenAM Account Lockout policies. Refer this KB article for more differences between OpenAM and OpenDJ lockout polices. 

Using OpenAM "Account Lockout" policies, users may get locked out with invalid login attempts. OpenAM offers both Memory and Physical lockouts. Using memory lockout, users get unlocked automatically after specified duration. 

Many deployments use "Physical lockout" due to security requirements. When this lockout mode is used then there should be some Self-service flow so that user can unlock themselves. Why not use OpenAM forgot password self-service flow ? 
OpenAM forgot password allows user to reset password after successfully completing various stages (such as KBA, email confirmation, reCaptcha etc). Unfortunately, the problem is that the account is not unlocked when this flow is used. There is already an open RFE for this issue.  

Solution

Versions used for this implementation: OpenAM 13.5, OpenDJ 3.5
One of the solution can include extending out of the box OpenAM's forgot password self-service flow by adding custom stage to unlock user's account: 

• Implement ForgottenPasswordConfigProviderExt to include account unlock stage. 
• Implement unlock custom stage
• Extend selfServiceExt.xml to include custom provider.

Deploy

• Build the custom stage by using maven.
• Delete all instances of User Self-Service from all realms.
• Remove existing selfService

./ssoadm delete-svc --adminid amadmin --password-file /tmp/pwd.txt -s selfService

• Restart OpenAM
• Register custom selfService
• Restart OpenAM

./ssoadm create-svc --adminid amadmin --password-file /tmp/pwd.txt --xmlfile ~/softwares/selfServiceExt.xml

• Add User Self-Service to specified realm and enable forgot password flow.

Testing

1. Lock user by authenticating using wrong password till user is locked out.
2. Follow forgot password flow to reset password and unlock account.
3. Try authenticating again with new password. This should succeed.

See Also

Get code
Understanding OpenAM and OpenDJ account lockout behaviors
Configuring OpenAM Account Lockout
Memory vs Physical OpenAM lockouts

Extending OpenAM HOTP module to display OTP delivery details

OpenAM provide HOTP authentication module which can send OTP to user's email address and/or telephone number. By default, OpenAM doesn't displays user's email address and/or telephone number while sending this OTP. 

Solution

Versions used for this implementation: OpenAM 13.5, OpenDJ 3.5
One of the solution can include extending out of the box OpenAM's HOTP module: 

• Extend HOTP auth module (openam-auth-hotp). 
• Update below property in extended amAuthHOTP.properties: send.success=Please enter your One Time Password sent at
• Extend HOTPService appropriately to retrieve user profile details. 
• Change extended HOTP module code as per below (both for auto send and on request): 

substituteHeader(START_STATE, bundle.getString("send.success") + <Get User contact details from HOTPService>);  

Deploy

• Build the custom auth module by using maven.
• Deploy the custom auth module. Refer instructions: Building and Installing Custom Authentication Modules 

Register service and module (Note that for OpenAM v12 use amAuthHOTPExt-12.xml) :
$ ./ssoadm create-svc --adminid amadmin --password-file /tmp/pwd.txt --xmlfile ~/softwares/amAuthHOTPExt.xml
$ ./ssoadm register-auth-module --adminid amadmin --password-file /tmp/pwd.txt --authmodule com.sun.identity.authentication.modules.hotp.HOTPExt

UnRegister service and module (in case module needs to be uninstalled) : 
$ ./ssoadm unregister-auth-module --adminid amadmin --password-file /tmp/pwd.txt --authmodule com.sun.identity.authentication.modules.hotp.HOTPExt
$ ./ssoadm delete-svc --adminid amadmin --password-file /tmp/pwd.txt -s sunAMAuthHOTPExtService

• Configure HOTPExt module with required SMTP server. Enable both SMS and Email.
• Create a chain(otpChain) with (LDAP:Required, HOTPExt:Required). Set this chain as default for "Organization Authentication"
• Restart OpenAM
• Invoke HOTP module and appropriate message is displayed on screen with user's email address and/or telephone number: 

See Also

Get code: https://github.com/CharanMann/OpenAM-HOTP-Extended 
OpenAM HOTP Authentication Module
OpenAM Custom Auth module sample

OpenAM SP SAML Attribute Mapper extension for updating profile attributes

OpenAM can act as both SP and IdP for SAML webSSO flows. OpenAM also provides ability to dynamically create user profiles.

When OpenAM is acting as SAML SP and Dynamic user profile is enabled, if user profile doesn't exist on OpenAM then OpenAM dynamically creates this profile from attributes in SAML assertion. 
The problem comes if user profile is updated at IdP side, all subsequent SAML webSSO flows doesn't update these changes at OpenAM SP side. More details here: OPENAM-8340

Solution

Versions used for this implementation: OpenAM 13.5, OpenDJ 3.5

One of the solution can include extending OpenAM SP Attribute Mapper. This extension may include just checking if user profile exists in OpenAM SP and updating any modified or new attributes in OpenAM datastore. Some tips for this implementation:

1. Extend DefaultSPAttributeMapper and override getAttributes()
2. Get datastore provider from SAML2Utils.getDataStoreProvider()
3. Check if user exists: dataStoreProvider.isUserExists(userID)
4. Get existing user attributes: dataStoreProvider.getAttributes()
5. Compare attributes in SAML assertion with existing user attributes. 
6. Finally persist any new and updated attributes: dataStoreProvider.setAttributes()

Deploy

• Compile and deploy this extension in OpenAM under  (OpenAM-Tomcat)/webapps/openam/WEB-INF/lib 
• Change SAML attribute setting in OpenAM. Navigate to Federation > Entity Providers > (SP Hosted Entity) > Assertion Processing. Specify 'org.forgerock.openam.saml2.plugins.examples.UpdateDynamicUserSPAttMapper' under Attribute Mapper.
• Restart OpenAM
• And we are good to go! Any changes in user profile attributes in SAML assertion will now be persisted in OpenAM datastore.

Note that ideally attributes between different sources should be synced by using some tool like OpenIDM 

See Also

Get code: https://github.com/CharanMann/OpenAM-SAMLSP-updateDynamicUser 
OpenAM User Profile settings: https://backstage.forgerock.com/docs/openam/13.5/admin-guide#auth-core-realm-attributes 
OpenAM SAML configuration: https://backstage.forgerock.com/docs/openam/13.5/admin-guide#chap-federation