Implementing remember me functionality – part 1

It’s quite common requirement to have long running sessions within OpenAM, so I’m going to try to enumerate the different ways to achieve “persistent” sessions and provide some comparison.
There is two main way to achieve long running sessions:

  • Using built-in functionality
  • Implementing custom authentication module + post processing class

Today we are only going to deal with the built-in persistent cookie features, the next article will describe the more user-specific solution.

Setting Expires attribute on session cookie

By default OpenAM issues session cookies without Expires attribute, meaning the cookie is only stored until the browser is stopped/restarted. This solution is especially handy if you have large session timeout values set, because in any other cases your session cookie would be saved in the browser for a good while, but the underlying session could have already time out.
Now there are two ways to enable this mode:

  • Enable persistent cookies globally for all sessions:
    Go to Configuration -> Servers and Sites -> Default Server Config -> Advanced tab, then add the following properties:

    openam.session.persist_am_cookie=true
    com.iplanet.am.cookie.timeToLive=100
    
  • After doing so you will probably need to restart the container for the changes to take effect. Any new sessions created afterwards will set the Expires attribute on the session cookie.
    When using DAS you need to set these properties in the DAS configuration file instead.

  • Allow to have persistent sessions on-demand:
    Go to Configuration -> Servers and Sites -> Default Server Config -> Advanced tab, then add the following properties:

    openam.session.allow_persist_am_cookie=true
    com.iplanet.am.cookie.timeToLive=100
    

    In this case to get a persistent cookie you need to include the openam.session.persist_am_cookie=true parameter on the Login URL (so you can’t actually put this on the Login form unfortunately)

  • When using DAS you need to set these properties in the DAS configuration file instead.

NOTE: the timeToLive value is in minutes.
NOTE 2: these properties only fully work on the core servers if you have OPENAM-1280 integrated, but if you use DAS these should work just fine.
NOTE 3: the timeToLive value only tells how long the cookie should be stored by the browser, it has absolutely NO influence to the actual session timeout intervals.

Creating a long living non-session cookie

When using this option OpenAM will create a second “DProPCookie” cookie next to the iPlanetDirectoryPro cookie with an encrypted content. This encrypted cookie stores a set of informations that are necessary to “recreate” a session when a user goes to OpenAM without a valid session cookie, but with a valid persistent cookie. OpenAM then decrypts the cookie and based on the stored information, it will create a new session.
In order to enable this persistent cookie mode you need to go to Access Control -> realm -> Authentication -> All Core Settings page and do the followings:

  • Enable the “Persistent Cookie Mode” option
  • Set “Persistent Cookie Maximum Time” option

After this when you include the “iPSPCookie=Yes” parameter on the login URL, or you have an actual checkbox on your Login.jsp submitting the exact same parameter during login, OpenAM will issue the DProPCookie persistent cookie with the configured timeout.
This method does not seem to be implemented for DAS.
NOTE: OpenAM will delete the persistent cookie as well, when the user logs out.
NOTE 2: due to a possible bug (OPENAM-1777) OpenAM may not invoke Post Authentication Processing classes when it recreates the user session.

Conclusion

As you probably noticed, the Expires on session cookie method is only really useful when you have large timeouts, also it is a global option, meaning that once you enable it, it will be set for all the different realms.
On the other hand DProPCookie is configurable per realm, but it does not seem to work when using DAS.

That’s all folks, this is how the built-in persistent cookies work, if these do not seem to match your requirements, then stay tuned for the next post.

Configuring Oracle OIF for Salesforce.com SAML SSO


Here is a quick how-to on configuring Oracle Identity Federation (OIF) as the SAML Identity Provider for Salesforce.com.

This turns out to be surprisingly easy to set up. For pre-requisites you should have the following in place:

  •  It is easiest if your OIF instance is configured to use POST SAML bindings by default. You can  override this on a provider basis but most often you will use POST, so it makes sense to set it as the default.
  • You need a salesforce.com account. Developer accounts are free and support SAML.
  • Create a user in your ldap for testing SAML SSO. We will match on the users "mail" attribute. Set this to a relevant value (testuser@example.com). The mail attribute does not need to match the salesforce.com account id. 
  • This example assumes we are using OAM as the authentication engine for OIF, and they both are referencing the same ldap server. 


Step 1 is to import your OIF IdP cert into salesforce.com.  The cert is available at http://example.com/fed/idp/cert (where example.com is replaced by your install domain /port). For example:



Save this cert to a text file, and import it into salesforce.com.  The salesforce SAML SSO setup is under the Security Controls left hand nav bar:


(Click on the image to enlarge it)





On the salesforce SSO setting page perform the following:

  • Import the saved certificate file.
  • Set the issuer to the provider id for OIF. This is available from the OIF console under "Identity Provider" properties. It usually of the form:  http://yourserver:7499/fed/idp. Note that the provider id must be a url format - but the id itself is opaque. In my example OIF is actually not available on port 7499 - but that's OK. The provider id is just for matching purposes.
  • Check the SAML id user type and location as shown above
  • Enter "mail" as the attribute name
After saving your changes, export the salesforce.com metadata and save it to a file.

At this time you should also set the salesforce.com Federation Id for your test user to match your ldap user email attribute. This is under the salesforce.com  menu:
  • Personal Setup -> My Personal Information -> Personal Information -> Edit. 

You want to set the Federation Id under Single Sign On Information:





On your OIF console, navigate to Admin -> Federations and import the saved meta data:





If your defaults in OIF are correct, you are most likely "done".  Test SSO out by going to the following url:

http://yourserver.com/fed/idp/initiatesso?providerid=https://saml.salesforce.com


Pro tip: The Firefox SAML tracer plugin lets you view what is being sent in the assertion.

If federation is not working the most likely cause is that the federation id does not match, or OIF is not sending the right attribute.

You can edit the salesforce.com provider settings in OIF to fiddle with this. For example:


You can also add an explicit attribute mapping (hit the "Edit" button above to add a mapping)

With my OIF defaults it "just worked". YMMV



Rotating debug logs

Since OpenAM 10.0.0 it is possible to enable time based debug log rotation in order to make your log files a bit more managable. Time based as in the logs will be rotated periodically after a configurable amount of time has passed.
Now the problem with debug logs is that they get written to in the very early phase of the startup process: just think about the fact that an error can occur already while trying to connect to the configuration store. This means that to store the rotation config, we can’t actually use the service config system, as by the time those settings get loaded, files are already written. To overcome this problem, instead, you need to modify/create files in the WAR file to make these configurations accessible for startup as well.
To enable debug log rotation, you need to create/modify the WEB-INF/classes/debugconfig.properties file:

org.forgerock.openam.debug.prefix=mylogs-
org.forgerock.openam.debug.suffix=-MM.dd.yyyy-kk.mm
org.forgerock.openam.debug.rotation=

The properties in detail:

  • org.forgerock.openam.debug.prefix (optional): an arbitrary string that will be used as a filename prefix for every debug log
  • org.forgerock.openam.debug.suffix (optional): a valid Java dateformat string. Please note that if you set up rotation for every 5 minutes and you don’t include minutes in the format string, then you won’t really rotate the debug log every 5 minutes (the logs won’t get overwritten, you’ll just have one log file with all the content).
  • org.forgerock.openam.debug.rotation: rotation interval for the debug logs in minutes. If rotation interval is higher than 0, then rotation is enabled

Since this has been implemented in the shared Debug class, this also means, that you can put this properties file on ClassPath for any OpenAM component that is using the ClientSDK, so things like DAS and Java EE agents too.
Obviously after creating/modifying the properties file, you have to restart the container for the changes to take effect.