Tuesday, September 12, 2017

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.

Wednesday, June 28, 2017

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.5One 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:

Friday, April 28, 2017

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:

Extend DefaultSPAttributeMapper and override getAttributes()

Get datastore provider from SAML2Utils.getDataStoreProvider()

Check if user exists: dataStoreProvider.isUserExists(userID)

Get existing user attributes: dataStoreProvider.getAttributes()

Compare attributes in SAML assertion with existing user attributes.

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