How to achieve the design requirement using OPENAM

Tagged: ,

This topic contains 1 reply, has 2 voices, and was last updated by  Andy Cory 11 months ago.

  • Author
  • #20510


    I am new to OPENAM and working on a POC where we need to replace the current SAML based security middleware with OPENAM. We need to replace the steps 3 and 6 with OPENAM.

    Can someone please guide me how can this be achieved using OPENAM? What all configurations do I need to do take care of in order to achieve the use case using OPENAM?

    Below is the current workflow for security implementation:
    1. A user will be logged into a 3rd party web site.

    2. The user presses a button/link on that website to post a SAML assertion to the middleware (1 and 2). This assertion will contain the user that is logged in (usually the employee id) as well as optional other attributes which should also be passed.

    3. The middleware receives the assertion. The middleware is currently multi-tenanted, and hold configuration at a per client/application level (i.e. multiple application configurations for each client)

    4. The middleware works out which client/application the assertion is meant for (this is done by looking up configuration for the entity id passed in on the assertion

    5. The middleware then calls a SECURE REST service on the application. This service is passed both the user identifier and the optional attributes, and, if the user is valid and login is allowed, it will return a token to the middleware

    6. The middleware will then send a redirect to the browser, setting this token as a cookie

    7. The browser then redirects to a backdoor service on the application, which reads the token out of the cookie, checks it is valid, and if it is, lets the user SSO into the requested page, redirecting it in the process.

    Any help would be much appreciated.

    • This topic was modified 11 months ago by  MohiniM.
     Andy Cory 


    If OpenAM is replacing your middleware, then won’t it need to handle steps 3 to 6, not 3 and 6? Steps 4 to 6 are some sort of secondary authentication I guess? Though your user has already authenticated to the identity provider in step 1.

    OpenAM provides extension points in which you can specify custom Java classes that run at certain points in the SAML flows. One example is SAML2ServiceProviderAdapter, which has hooks that are called following certain events. One such hook is postSingleSignOnSuccess – you could add code here to call a REST service on your application(s) and handle the response. The HttpServletResponse is available in that method, so I don’t see why a cookie shouldn’t be set at this point. The SSOResponse object passed into this method can be used to determine the entity ID from the assertion.


Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.

©2018 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?