SSO for IdP – IoP Optimization and Alternatives using SAML. DAuth, WS- TR

Session Topic: Federated SSO for Multi-Party (IdP-IdP) with Standards Based Solutions and Maximize Interoperability.

Tuesday 5E

Convener: Steve Tout

Notes-taker(s): Steve Tout

Problem: Discuss various ways to build federated SSO for multi-party, where IdP looks to federate access with another IdP, and develop a standards based solution and maximize interoperability.

Discussion:

• Steve provided high level overview of Use Case
  • IdP #1 wants to send SAML assertion and SSO user into the IdP #2 premises and into a target destination (as opposed to a generic landing page or dashboard)
  • IdP initiative SSO
  • N number of target systems in IdP #2 which a user might need to SSO into, and most cases are unique to the user
  • Explained that SP initiated SSO is already proven and not a requirement
• Fielded questions about nature of target applications
  • Explained that target application may or may not be SAML compliant, and one should not assume that it will be. In other words, it could use Kerberos, WS-Trust, access token, etc…)
• General confusion and questions about why there is no SP in the initial drawing on whiteboard
  • Explained the requirement that to not be forced into having a 1-to-1 relationship between SP and downstream target system and thus the desire to avoid having an SP profile for each target system
• Peter made the suggestion to look at the Delegated Auth portion of the SAML spec (which he contributed) as possible use in the solution
• Peter shared his experience implementing a “Concierge Service” for UltraViolet to abstract the underlying authentication mechanisms or protocols and suggested that a stronger protocol bridge/architecture was needed in order to realize what he thinks is trying to be achieved in the use case presented
• Several folks who are contributors to the original SAML spec (such as Peter and Prateek) and few others chimed in to explain that this is the classic use case for SAML
• Paul jotted down a high-level flow of how the interactions between IdPs and subsequent down-stream protocol conversions would work together
• Chuck encouraged the strict use of HTTP and URLs for evaluating incoming requests and parsing in order to route it to the appropriate authentication protocol or mechanism that can support that request
• Prateek made mention that the SAML spec made provision for this exact use case
• The general consensus among attendees was that this use case would not be possible without the use of a SP profile on IdP #2 and that the solution is made more dynamic and scalable by having a some type of protocol bridge/proxy or concierge service to handle the routing and upstream/downstream conversion of Authentication request types

Whiteboard: