Browse Prior Art Database

Leveraging a SSO mediator for cloud based multi-level SSO patterns

IP.com Disclosure Number: IPCOM000244034D
Publication Date: 2015-Nov-06
Document File: 3 page(s) / 66K

Publishing Venue

The IP.com Prior Art Database

Abstract

In a cloud based environment the users still see a seamless integration and security SSO as given. To allow this technology needs to adapt the onPrem concepts and enrich them to also allow interactions in a cloud system. Instead of the full admin control, same domain und easy exchange of keys it needs to get more flexible as soon other partners are connected as it is usual in the cloud. To support this change in technology there are already SSO concepts in place which allow seamless login processes between different vendors as soon a trust relationship was established. Those protocols known as openID, OAuth, OpenID Connect, SAML and others work since years. But now - as the systems get more and more complex - some details are used that where not covered in the initial design of those solutions. This article focus on the challenge to allow multi-level SSO between different servers reusing given trust relationships. In a cloud environment SSO is essential for a satisfactory user flow. This SSO needs to be user-based (no technical user) to allow data integration based on user scoped information. For a front-side SSO there are solutions in place and covered via standards. Also Back-End SSO is already discussed and possible. But if a local browser interacts with a cloud server instance that again needs to authenticate against a 3rd party system a technical scenario appears that is not covered in detail already. This scenario can get solved by a SSO mediator System that leverages given infrastructure and protocols to enable this new functionality. By a combination of different SSO a new possibility to achieve the initial login goal can be solved. This requires redirect handling and three SSO domains (or more) to work together. The User enters the system via Front-Side SSO and is known by the system. The system is requested to obtain additional information from a backend system on behalf of the user. There is no direct trust relationship possible between the system and the backend.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 3

Leveraging a SSO mediator for cloud based multi -

A trust relationship between a ServiceProvider and an Identity provider works very well based on current configurations. But in complex systems it may appear that one cloud system needs to establish another secure SSO to a 2nd cloud system.

PortalSystem:

The only system the user browser will interact to. Working as proxy for all connected backEnd systems. To allow user-based information from 3rd party systems this server needs to be able to identify to other systems with the user context. Those 3rd party systems did not change to allow ssystem2system integration - given that the portalServer is only able to use the same interfaces to the system as a user would use.

PortalIdP:

This IdP is connected with the portalServer and by that in a trust relationship. The portalServer may identify as the user to this system e.g. by a generated security token. The portalIdP is able to generate tokens for other systems to identify e.g. SAML.

CloudIdP:

This IdP sit in the cloud and is available for different systems. There is a trust relationship established between this IdP and the portalIdP.

TargetSystem:

The target system hosts the business information for specific users. Users may login to this system using the cloudIdP. During the user identification this system detects the cloudIdP is the authentication server for this user and redirects to this server for that purpose. Only one of this configurations can be active for a user. That limits the possibility for login to a 1:1 relationship.

The initial flow covers the portalServer needs to retrieve data from the targetSystem for the actual given user. There is no trust relationship between the portalIdP and the targetSystem. But between the targetSystem and the cloudIdP. As well as between the cloudIdP and the portalIdP and the portalIdP and the portalServer.

Given this trust chain it is possible to do a recursive login process by a multi-level SSO pattern.

User did a login with the portalServer. portalServer try to call the targetSystem - logi...