So, you (believe) you've configured the agent to protect your application URLs as part of your SSO implementation. You attempt this by accessing the application URL and you're 302 re-directed to the forgeRock OpenAM login screen (so far so good).
Though this is when things go wrong. When you successfully authenticate, your browser throws a big wobble by stating that you've made too many redirects (ERR_TOO_MANY_REDIRECTS). Your localhost_access_log.txt will indicate that multiple 302 requests are returning back to the application. Basically the application that you're trying to access is not accepting the OpenAM cookie (or at least doesn't acknowledge a valid one) The application sends the browser to OpenAM for you to authenticate. OpenAM however acknowledges that you have an active session (and an active domain cookie) and basically says, 'Do don't need to auth again, you already have a valid token, go back to the application'.
An simple example is that the application 'app1.bus1.com' resides on a separate domain of OpenAM '.business1.com' and therefore the domain cookie differs.
How Can I see this happening?
Get a tracer. Chrome's plugin SAML tracer. cookie inspector
SOLUTION
ForgeRock has a functionality called cross-domain single sign on (CDSSO). Basically it will allow OpenAM to create a cookie to access different DNS domains to where OpenAM is deployed. So even though you're accessing app1.bus1.com, the policy agent will extract the SSOToken from LARES and sets the cookie domain to the FQDN of the resource, which is pretty cool!
To the material in question is, HOW TO: Enable CDSSO For a Java EE Policy Agent Obviously this is different for just web policy agents though the same document provides both just incase the page is unavailable, perform the following tasks
- In the OpenAM console, browse to Access Control > Realm Name > Agents > Web > Agent Name > SSO.
- Enable Cross Domain SSO.
- Set the list of URLs for CDSSO Servlet URL to the Cross Domain Controller Servlet URLs of the servers the agent accesses, such as http://openam.example.com:8080/openam/cdcservlet. If the agent accesses OpenAM through a load balancer, use the load balancer URLs, such as http://load-balancer.example.com:8080/openam/cdcservlet.
- Add the domains involved in CDSSO in the Cookies Domain List.
- If necessary, update the Agent Root URL for CDSSO list on the Global tab page. If the policy agent is on a server with virtual host names, add the virtual host URLs to the list. If the policy agent is behind a load balancer, add the load balancer URL to the list.
- Save your work.
About the author
Daniel is a Technical Manager with over 10 years of consulting expertise in the Identity and Access Management space.Daniel has built from scratch this blog as well as technicalconfessions.com
Follow Daniel on twitter @nervouswiggles
Comments
Other Posts
AS I was migrating my environment into an S3 environment, I wanted to leverage off the SES services that AWS provide, more specifically, to leverage the off the SMTP functionality by sending an email via PHP
Read More...
The WeMos D1 is a ESP8266 WiFi based board is an extension to the current out-of-the-box library that comes with the Arduino installation. Because of this, you need to import in the libraries as well as acknowledging the specific board. This process is highly confusion with a number of different individuals talking about a number of different ways to integrate.
Read More...
NameID element must be present as part of the Subject in the Response message, please enable it in the IDP configuration.
Read More...
For what I see, there's not too many supportive documentations out there that will demonstrate how provision AD group membership with the ICF connector using OpenIDM. The use of the special ldapGroups attribute is not explained anywhere in the Integrators guides to to the date of this blog. This quick blog identifies the tasks required to provision AD group membership from OpenIDM to AD using the LDAP ICF connector. However this doesn't really explain what ldapGroups actually does and there's no real worked example of how to go from an Assignment to ldapGroups to an assigned group in AD. I wrote up a wiki article for my own reference: AD group memberships automatically to users This is just my view, others may disagree, but I think the implementation experience could be improved with some more documentation and a more detailed example here.
Read More...
In the past, the similar error occurred though for the Oracle Identity Management solution. invalidcredentialexception remote framework key is invalid Because they all share the ICF connector framework, the error/solution would be the same.
Read More...
org.forgerock.script.exception.ScriptCompilationException: missing ; before statement
Read More...
ForgeRock IDM - org.forgerock.script.exception.ScriptCompilationException: missing ; before statement
Read More...
When performing the attempt of a reconciliation from ForgeRock IDM to Active Directory, I would get the following error
Read More...
In the past, the similar error occurred though for the Oracle Identity Management solution. invalidcredentialexception remote framework key is invalid Because they all share the ICF connector framework, the error/solution would be the same.
Read More...
During the reconcilation from OpenIDM to the ICF google apps connector, the following error response would occur. ERROR Caused by com.google.api.client.auth.oauth2.TokenResponseException 400 Bad Request - invalid_grant
Read More...