I need to know how to connect AM with Github through IG to be able to perform SSO, I have some difficulties in configuring IG routes. I want this connection to be password based not OAuth. Any Advise ?
Hi @MohamedSaad96,
Github support SAML2 SSO, have you considered this? e.g About authentication with SAML single sign-on - GitHub Enterprise Cloud Docs
IG has SAML2 support : SAML :: ForgeRock Identity Gateway
Have you been through this material?
Regards
Patrick
Thank you for your response, yes I considered the SAML2 SSO and already done it, I wanted to try out the password based approach as many of the legacy application does not support SAML and the client wants to unify the integration pattern, so is there any suggestion how to achieve this approach ?
Hi @MohamedSaad96,
At this point it is good to set back from the functional aspect, and contemplate the security aspect. What you are looking for is having a legacy app sharing SSO with AM outside of a standard federation architecture. I will assume that AM here is the trusted IDP. And each legacy app will need some session to certify and identify the user before allowing access to the (owned) protected information. Here is the dilemma:
- Only a session delivered by AM is to be trusted. But such session will not likely identify a user as per the legacy app.
- A session delivered by any app cannot be trusted (and therefore de facto exchanged for an AM session), as if a user is validated on one legacy app, it’s perhaps not the case for AM or any other apps - nothing proves that the user is known there.
- So ideally, the user would have to re-authenticate to legacy apps… but that’s not really SSO.
Unless credentials are unified across AM and all apps, this is not workable. On the other hand, you could emulate linking accounts between AM and legacy apps, just require the app password the first time the user logs in - stores it in a linked account for replay against the app next time. At this point you’ll need to consider which one requires less efforts:
- Build the custom solution
- Bring the legacy apps to a standard federation architecture.
Implementing this solution with IG is perhaps not the best option. This sounds more like an Identity Management role in cooperation with AM, and this is probably a substantial development effort.
Regards
Patrick
2 Likes
Thanks for your help and suggestions.
1 Like
Hello Patrick,
currently I have a password based application that is not supporting any of the federation protocols and I want my IG to connect to it so the end users are able to login using SSO.
So, is it possible for the IG or the AM to be configured for SSO as a password based or it’s not supported.
would appreciate your kind response on this
Hi @MohamedSaad96,
This is no a matter of whether this is supported by AM or IG, but rather how would you implement SSO without federation? The important questions to ask are the following:
- Do the users share the same credentials (username/password) in AM and the legacy app?
- How a user session is validated in the legacy app?
Regards
Patrick
Hello Patrick,
sorry for the late reply, well regarding these questions
Q: Do the users share the same credentials (username/password) in AM and the legacy app?
Ans: no they are different
Q: How a user session is validated in the legacy app?
Ans: The legacy application validates the session token received from ForgeRock AM to ensure its authenticity and integrity. This validation process may involve verifying the signature, checking the token’s expiration, and validating against the ForgeRock AM server.
I am confused @MohamedSaad96 - if all your apps go through AM for authentication - even legacy apps - then that’s already SSO, right?
But then you say that user credentials are different for the legacy apps… so I am confused now… is it connecting to a different realm?
This was a mistake from me,
Q: Do the users share the same credentials (username/password) in AM and the legacy app?
Ans: no they are different
Q: How a user session is validated in the legacy app?
Ans: from the legacy application itself.
In which case @MohamedSaad96 I don’t think it’s possible to have SSO with this legacy application in its current state. If the legacy app is in a different domain, I don’t see any other solution than migrating the legacy app to use federation… or porting the legacy app to use AM authentication.
The legacy application is in the same domain actually, and yes I want to use AM authentication because I configured it to use Active Directory as the source of authentication, the thing is the legacy applications have different usernames and passwords then the AD, is there a workaround in this matter?
Hi @MohamedSaad96,
Unfortunately, there is no magic wand in this matter, I can’t see how this can be achieved without some changes at the app level. This app is the only one to deliver its authentication proof, the session, and would not recognise any other format (e.g AM session token, SAML assertion, or id_token). You could of course imagine something along storing both credentials in a user profile so that AM could replay against the app… that’s complicated though, hard to maintain, and non standard.
Regards
Patrick
2 Likes