In my previous example there are some bits that could go wrong and
essentually result in a redirect loop. A redirect loop 90+% of the time
happens because of cookies and domains – i.e. misconfiguration. So what
happens is that OpenAM creates the cookie for its domain, but when the
user is redirected back to the application, the app/agent won’t be able
to find the cookie in the incoming request, but authentication is still
required, so it redirects back to OpenAM again. But wait, AM already has
a valid session cookie on its domain, no need for authentication, let’s
redirect back to the app, and this goes on and on and on. The most
common reasons for redirect loops:
- The cookie domain for OpenAM does not match at all with the protected application.
- The cookie domain is set to sso.example.com, instead of example.com, and hence the cookie is not available at foo.example.com .
- The cookie is using Secure flag on the AM side, but the protected application is listening on HTTP.
- Due to some customization possibly, the AM cookie has a path
“/openam” instead of the default “/”, so even if the cookie domain is
matching the path won’t match at the application.
- You run into one of the previously listed IE quirks.
- Your cookie domain for OpenAM isn’t actually an FQDN.
So how does OpenAM deal with applications running in different
domains? The answer is CDSSO (Cross Domain Single Sign-On). But let’s
discuss that one in the next blog post instead. Hopefully this post will
give people a good understanding of the very basic SSO concepts, and in
future posts we can dive into the more complicated use-cases.
