Data Store, LDAP User Attributes and Subjects

In my previous blog Global Session vs User Session, I mentioned how to go about configuring Session settings on a per-user basis. 

First, go to the Subjects tab and search for the User.

Then, we set a different Session setting for the user. In this example, we change the Maximum Idle Time for this user from the default 30 minutes to 60 minutes.

Fairly simple from UI perspective, but what really happens behind the scene?

There is a need to map Maximum Idle Time from the UI to an attribute in the user's LDAP entry. In this case, OpenAM makes use of an attribute iplanet-am-session-max-idle-time.

So that means OpenAM needs to be able to edit the user's LDAP entry. (see the other blog of mine) More importantly, the backend Data Stores (e.g. LDAP) must have the necessary attributes defined in the schema. (e.g. iplanet-am-session-max-caching-time, iplanet-am-session-max-idle-time, iplanet-am-session-max-session-time, iplanet-am-session-quota-limit)

In Data Stores, click on the appropriate backend. 

Scroll to the section LDAP User Attributes. Ensure that the necessary attributes are defined. 

Embedded OpenDJ
If the backend is an embedded OpenDJ that is installed together with OpenAM, then we are fairly sure the OpenDJ schema is populated with the required session attributes. The schema is defined in ...//opends/config/schema/99-user.ldif .

External OpenDJ
If the backend is an external OpenDJ, we need to ensure the external OpenDJ is chosen during OpenAM installation. The installation will ensure the appropriate attributes are created in 99-user.ldif.

If the external OpenDJ is configured post OpenAM installation, then we need to ensure 99-user.ldif from the embedded OpenDJ is copied to the the external OpenDJ. One can choose to load the schema manually with pre-defined ldif files in ...//ldif/opendj/.



The above 2 scenarios are quite straight-forward. What if the backend is Microsoft Active Directory or any of the supported user data stores?

Remember we said earlier that we need to load the necessary attributes into the OpenDJ schema? The same has to be done on any other User Data Stores. 

Well, this becomes tricky. 

Will the AD administrator allow non-AD related attributes to be created on the AD? Likely not. This is not a technical issue, but an operational one.


.