September 18, 2015 at 4:43 pm #5535mdave4Participant
I am trying to implement use case as follow :
We are having web application which has b2b setup, so as per my understanding we need to create multiple realm for each customer and for that we need to setup multiple IdP’s in OpenAM.
So I am able to test single realm with One IdP and SP setup, so now I am trying to test with same web application with multiple realm. so what kind of changes we need to do to accomplish this use case ?
Please let me know if there are some documentation related to this scenario?September 21, 2015 at 11:40 am #5546Robert MorschelParticipant
I’m just in the process of trying this myself. I have been sent this:
Peter Major’s overview of IDP Proxy scenarios at the IRM summit last year:
3 part article for setting up end-to-end SAML using IDP proxy:
SFDC SP/OpenAM IDPProxy/ADFS IDP:
Some info from the OpenSSO docs hosted on Oracle that provide the sequence diagrams explaining the role of the IDP Discovery service:
Best of luck. It has proven non-trivial so far.
RobertSeptember 23, 2015 at 4:31 pm #5575Peter MajorModerator
Oh god, people actually watch that presentation :)September 28, 2017 at 11:45 pm #19007
Is there an equivalent feature in OpenAM using OpenID Connect instead of SAML2)?September 29, 2017 at 5:18 pm #19025Nikolaos GiannopoulosParticipant
An IDP Proxy introduces a fair amount of complexity. You go from having:
IDP2 <==> OpenAM SP
IDP 1 .. IDP n <==> OpenAM IDP Proxy <==> OpenAM SP
and moreover as an IDP Proxy is effectively a singular mechanism with split SP and IDP metadata allowing it to map nicely to the typical SAML2 IDP/SP Host/Remote circle of trusts you would setup you end up having:
IDP 1 .. IDP n <==> OpenAM IDP Proxy (SP) <==> OpenAM IDP Proxy (IDP) <==> OpenAM SP
Something that helped me immensely is understanding that the SP side of the IDP proxy faces IDP 1 .. IDP n and the IDP side of the IDP Proxy faces the SP.
We have pushed the envelope quite hard with OpenAM and setup the following with SAML2, CD-SSO and HA/LBs and combined the IDP Proxy and SP into the same OpenAM instance but in different realms with DNS realm aliases and even scripted the full install in PowerShell:
IDP1, IDP2 <==> OpenAM IDP Proxy (SP) <==> OpenAM IDP Proxy (IDP) <==> OpenAM SP <==> OpenAM Agents w/ CD-SSO
Overall I looked at the 3 part articles and they were somewhat helpful but I did a ton more research to get the various parts working. In the end it doesn’t seem that complicated when you are done but when you are building it I agree it is non-trivial and in my case largely involved a lot of trial and error and self-discovery.
Good Luck!April 16, 2018 at 4:53 pm #21491
I’d like to re-ask my earlier question which was never answered:
Is there an equivalent feature to provide IdP Proxy in OpenAM using OpenID Connect instead of SAML2?
AndrewApril 17, 2018 at 6:53 am #21500Peter MajorModerator
If you use the authorize/implicit flows, then you could use OAuth2 authentication modules to achieve something similar, though strictly speaking the initiating OAuth2 request and the “proxied” request will have not much to do with each other.April 19, 2018 at 5:59 pm #21534
Thanks Peter. We use the authorize flow today. This gives me hope that this is possible using simpler Oauth2 protocols. The SAML2 proxy config seems pretty complicated and makes my head hurt thinking about supporting that across 4 environments with multiple IdPs. I would love a simpler solution.
After staring at the documentation for a few hours, unfortunately I’m still not seeing an obvious path from OAuth2 auth modules to how one would mimic the IdP proxy flow. Since OpenID Connect is so straightforward, it almost seems easier to just do this in a simple web bypassing OpenAM completely. But before I try to reivent the wheel, I was hoping you could be so generous and outline, at a high level, how you might imagine OpenAM could do this? I have my own Login site/UI.
I realize this is asking a lot, so I understand if it’s beyond the scope of this community forum.
Questions I have:
* How would Open AM proxy the OIDC authorization request to the downstream IdP after an OIDC authorization request comes in to OpenAM?
* Along those lines to how we can create/mimic IdP Finder functionality? I could probably do this in my UI app after the user enters their username, but somehow I need to send this IdP info to OpenAM to start the OIDC authorization request to that IdP.
* How does OpenAM translate the id_token received from the downstream IdP to an OpenAM id_token? Is this a custom OIDC Claims script?
Right now I’m just trying to understand how much of this could be accomplished in OpenAM versus in my Login app (that is currently regisered in the OAuth2 Provider ‘Custom Login URL Template’.)
Any help is appreciated,
AndrewJune 12, 2018 at 5:28 pm #22287
I think I figured it out (answered my own question). Just to provide some context, we already have a small web app that acts the front-end the users see when they authenticate. It communicates with OpenAM on the back-end over REST.
We utilize the OAuth2/OIDC auth module to enable ForgeRock to acts as a relying party and federate authentication to an downstream IdP (any IdP that supports OIDC). The trickiest part was figuring out how to get OpenAM to send the authorization_code back to my login app instead of OpenAM itself. It did this by modifying the ORIG_URL cookie that OpenAM sent back to my Login app when it started the auth flow (with a back-channel POST). It changed the value of that cookie to the URL of my Login App (/federatedComplete) . Once my login app receives the authorization code (step 10), then then it completes a back-channel POST to OpenAM to complete the authentication process and create an OpenAM session.
It will depend on your realm settings as to whether you require the user to have a profile in your user data source (OpenDJ). Since we use SAML2 in this environment, we do require it. This means that a user is auto-created in OpenDJ if the user does NOT already existing in OpenDJ. But OpenAM/OpenDJ never see the user’s actual password that they used to authenticate with the federated IdP.
Here are the high level steps… there are lot of implementation details that were left out, but hopefully this helps others get start if they have a similar use case.
1. User visits relying-party app.
2. Relying party starts auth flow with FR (SAML2 or OIDC).
3. FR redirects user to Login app to authenticate.
4. User enters only their username (email) in the Login app.
5. The login app decides if the user can/should authenticate with ForgeRock or some other IdP (like AD, or an external client IdP).
5a. If Login app decides user should authenticate with Forgerock, then the user enters their password in the Login app.
5b. User completes normal authentication process with ForgeRock to a create a ForgeRock session (and iPlanetDirectoryPro cookie)
5c. Skip to step 13.
6. Login app starts OIDC auth flow with federated IdP, indirectly. It does this ‘through’ back-channel REST call to ForgeRock. The Login app doesn’t speak to the federated IdP directly. ForgeRock has an OIDC Authentication Module for each registered IdP. The Login app first wants the Federated Auth URL.
7. ForgeRock starts an auth session for the OIDC Auth Module and returns to the authentication URL for the federated IdP.
8. The Login app redirects to the Federated Auth URL. This is essentially starting another OIDC flow, this time between ForgeRock and the other IdP. But now, ForgeRock is the relying-party wanting identity information from the federated IdP. The redirect_url from the federated IdP will be back to ForgeRock.
9. The user authenticates with the federated IdP. Upon success, it redirects to ForgeRock with the OIDC authorization_code.
10. ForgeRock redirects to the Login App, /federateComplete endpoint, to complete the OIDC flow with the OIDC Auth Module.
11. The Login app performs a back-channel REST call to ForgeRock with the authorization_code (and related auth cookies set in step 7) to create a ForgeRock session.
12. ForgeRock creates a session and return the session id.
13. The Login app creates a cookie from the ForgeRock session Id and returns it to the browser as the iPlanetDirectoryPro cookie.
14. The Login app completes a final redirect back to ForgeRock to complete the OIDC flow initiated by the relying-party in step 2.
15. ForgeRock returns the authorization_code to the relying-party (for the first OIDC flow).
16. The relying party completes the OIDC flow to exchange the authorization_code for an id_token.
- This reply was modified 4 months, 1 week ago by firstname.lastname@example.org.
You must be logged in to reply to this topic.