The Timeout Value attribute of the Policy condition Authentication by Module Instance defines when the application (defined as the value of the Application Name attribute of the Policy condition Authentication by Module Instance) should force re-authentication.
CAUTION : The application name (app_name in session below) is a grouping of resources being protected. For example, all resources that constitute the paycheck application can be defined as paycheck. So, if the same app_name (in this case, paycheck) is used in two different policies with different Timeout Value values, the result is randomly picked up.
An authenticated user can lose access to a protected resource after a defined amount of time has passed (from the time of authentication). If the user attempts access after the time is up, the policy agent will force authentication again using the scheme configured in the Authentication by Module Instance condition. After successful authentication, the user will again be allowed access to the resource. Re-authentication will be required to access the protected resource, if idle, regardless of the session time limits. (If the Timeout Value is longer than the maximum session time, the user will not be affected by it but, if the session's idle timeout is reached, the session will timeout.)
For example, assume Application A and Application B are configured for single sign-on. Additionally:
Application A has a Timeout Value equal to 10 minutes
Application B has a Timeout Value equal to 60 minutes
A user successfully logs in to Application A and receives a session token. When the same user accesses Application B, no additional authentication is needed. But, after ten minutes of idle time, Application A requires re-authentication. A use cases for this attribute might be when user jdoe logs in to a protected application configured for re-authentication after 10 minutes of idle time (from the time of authentication set in the session). jdoe leaves the public computer with out closing the browser, and user jsmith arrives ten minutes after and attempts to access the resource again. The login page is displayed and jsmith must authenticate before access is permitted.
One thing to keep in mind is that this attribute value does not depend on the session time limit. For every time authentication is forced, the moduleAuthTime property in the session token is checked against the value of the Timeout Value condition in the policy. A typical session might look like this:
The following properties in the session are relevant.
NOTE : The protecting policy agent should run in self policy decision cache mode and the com.sun.am.policy.am.fetch_from_root_resource property should be set to false.
I'm taking tomorrow off to spend the weekend in Yosemite. 65 years ago, Spike Jones and his City Slickers made a soundie that neatly sums up how I feel having three days off.
There are two ways to configure Sun Java System Directory Server Enterprise Edition (DSEE) as the user data store for OpenSSO.
By configuring DSEE as a user data store during deployment.
By preparing the DSEE manually.
The first option is easy-breezy. When you first launch OpenSSO, the configurator is displayed. By checking the Load UM Schema option and pointing to the instance of DSEE, that instance will be configured as the user data store.
The second option is a little less breezy. Follow this procedure to configure DSEE manually.
Load the user attribute schema and index files into DSEE using ldapmodify.
ldapmodify -h host -p port -D"cn=directory manager" -w passwd -c -f file-nameTIP: If you run into a SASL BIND error, use the -x option with ldapmodify.
The schema and index files\* are (and can be found in):
path-to-context-root is specific to the web container on which OpenSSO is deployed.
\*NOTE: The schema files are platform and root suffix neutral; you can retrieve these files from any instance of OpenSSO and load them to any other instance. The index files, on the other hand, are not neutral. index.ldif and fam_sds_index.ldif contain the back-end database name of the instance to which they were originally deployed. For example, if originally deployed in a system with a dc=red,dc=sun1,dc=com root suffix, an index entry might look like:
dn: cn=nsroledn,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config dn: cn=memberof,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config dn: cn=iplanet-am-static-group-dn,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config dn: cn=iplanet-am-modifiable-by,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config dn: cn=sunxmlkeyvalue,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config dn: cn=o,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config dn: cn=ou,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config dn: cn=sunPreferredDomain,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config dn: cn=associatedDomain,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config dn: cn=sunOrganizationAlias,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config
Thus, in order to use these index files on a system with the root suffix of dc=sun2,dc=com, replace all occurrences of red in the files with sun2 before loading.
Prepare the DIT for the default Data Store configuration by creating the base container entries.
Copy the following text into a file named /tmp/new/ldapentries.
NOTE: Be sure to replace dc=sun,dc=com with your root suffix.
Run the following command:
ldapmodify -h host -p port -D"cn=directory manager" -w passwd -c -a -f /tmp/new/ldapentries
Now you can login to OpenSSO and create a data store with the FAM schema using DSEE. The bind DN is cn=dsameuser,ou=dsame users,ROOT_SUFFIX.
Now to remind you just how easy that was - here's the Barenaked Ladies with Easy.