CODEWITHSUNDEEP
authenticationcookiespersistenceopenamopensso
mr_van
mr_van

Reputation: 105

SSO cookie not working when using persitent cookie in openam/opensso

I have started maintain a number of websites that are all authenticated using openam SSO. However when one of our users sets a persistant cookie (DProPCookie) it doesn't always work.

Repro scenario is:

  1. Login to openam, setting the persistant cookie
  2. Restart browser (to clear session cookies)
  3. Go to site A, user is logged in automatically because of persistant cookie
  4. Go to site B, user is presented a login page (they should be automatically logged in).

After step 3, if I delete the iPlanetDirectoryPro cookie from my browser I can login to site B fine (using the persistant cookie). It seems that the iPlanetDirectoryPro cookie generated from Site A when the DProPCookie is set doesn't work on Site B.

Note that I have tried with various permutations of Site A and B and the scenario is the same in each case.

I'm quite new to openam so any hints as to how to debug this would be great or if I'm missing something obviously going wrong please do let me know.

Thanks in advance.

EDIT:

I have subsequently discovered that the iPlanetDirectoryPro cookie returned when authenticating using the DProPCookie isn't working. So thus has nothing to do with cross domain.

  1. Login to openam, setting the persistant cookie
  2. Restart browser (to clear session cookies)
  3. Go to site A, user is logged in automatically because of persistant cookie
  4. Delete all cookies except iPlanetDirectoryPro cookie
  5. Refresh page - asked to login

If I repeat the test but with the iPlanetDirectoryPro cookie generated by a normal login then when I refresh the page, I automatically get authenticated. (I have changed the title of the question to reflect this).

FURTHER EDIT:

Turned up debugging - am seeing this exception in the logs:

IdName is :null
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
orgName is :xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity() from IdUtils Name: null Org: xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity: Got IdRepoException while getting Identity from IdUtils: Illegal universal identifier null.
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
isLockedOut:Exception :
java.lang.NullPointerException
        at com.sun.identity.idm.server.IdCachedServicesImpl.search(IdCachedServicesImpl.java:585)
        at com.sun.identity.idm.AMIdentityRepository.searchIdentities(AMIdentityRepository.java:296)
        at com.sun.identity.authentication.service.AuthD.getIdentity(AuthD.java:1453)
        at com.sun.identity.authentication.service.AMAccountLockout.isMemoryLockout(AMAccountLockout.java:297)
        at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:281)
        at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:264)
        at com.sun.identity.authentication.service.AMLoginContext.processPCookieMode(AMLoginContext.java:1919)
        at com.sun.identity.authentication.service.AMLoginContext.processIndexType(AMLoginContext.java:1846)

A quick scan through the openam code - it appears that we are not getting a username here in AMAccountLockout.java:264:

   public boolean isLockedOut() {

       // has this user been locked out.

       String userDN = loginState.getUserToken();

       return isLockedOut(userDN);

   }

Upvotes: 1

Views: 3804

Answers (3)

mr_van
mr_van

Reputation: 105

Ultimately we discovered that the problem was that the SSO cookie generated by the persistant cookie had no authention modules - and therefore the authentication level was set to Integer.MIN_VALUE;.

In our situation we made a slightly hacky fix to force this to be 0 instead, which fixes up the problem.

I presume the correct thing to do would be to either have a seperate authentication module for persistant cookie logins or to store the authenticating module in the SSO cookie generated by the Persistant cookie.

Upvotes: 0

Peter Major
Peter Major

Reputation: 2995

Could be that you are running into https://bugster.forgerock.org/jira/browse/OPENAM-1002 ? Also it could be a problem with your cookie domains, maybe site B redirects to a different domain where DProPCookie is not visible?

Upvotes: 1

Bernhard Thalmayr
Bernhard Thalmayr

Reputation: 2744

Persistent Cookie mode has changed in OpenAM ... DProCookie is actually not used anymore.

Posssibly you're running 'restricted token mode' AKA 'cookie anti-hijack mode' and CDCServlet does not issue a proper authentication assertion

Upvotes: 1

Related Questions