CODEWITHSUNDEEP
securityoauth-2.0single-sign-onstormpath
ga016556
ga016556

Reputation: 75

SSO for two applications that use different identity providers

I want to perform SSO between two web apps. Here is my scenario:

Apps A & B (both provide RESTFUL API). App B uses form based authentication and I can not make any modifications to app B. Also, app A and app B maintains different user stores for authentication.

User registers in App A and after successfully registering, it logs in to app A and calls an API from app B that require user authentication.

The goal is to ensure that once user logs into app A they should be able to call authenticated API of app B without the need for logging in app B again.

I went through the cloud based SSO solutions provided by PingIdentity, Stormpath and few other vendors and it looks like for SSO across multiple applications require that either all the applications should trust same identity provider or the apps should understand SAML/Open ID. Also, it would require me to change the way app B handles authentication (but I can not make any changes to app B.

I have thought of simple solution for my scenario (which in a way is also an SSO approach http://www.opengroup.org/security/sso/sso_intro.htm)

Once the user logs in to App A, the server will make a background login call to App B (using pre-configured default credentials for App B). In response to this login, app B will issue a session cookie which would be passed in subsequent API calls to App B. This approach has drawbacks of using default credentials for app B but it's simple and would work.

However, before going this path, I wanted to know if this scenario can be handled in different way using standard SSO solutions ?

Upvotes: 3

Views: 4872

Answers (1)

afitnerd
afitnerd

Reputation: 736

Traditionally, there is some "glue" that binds SSO applications together. There needs to be inherent trust between the two applications. This is commonly done with protocols (SAML / Open IDC) or shared secrets (for validating signatures).

In the scenario that you are describing, where you have no control or access to how App B authenticates, you would always need to authenticate "in the background" to App B and hold on to its session cookie for subsequent requests.

However, this is inherently insecure. It's effectively creating an anonymous login to App B that you are using for all users of App A. As far as App B is concerned, it will always be the same user logging in.

If you had the ability to create an account in App B such that for each account in App A you had an analogous account in App B that you logged in to, that would be more secure.

Hope this helps!

Full disclosure: I work for Stormpath.

Upvotes: 4

Related Questions