RE: [saml-dev] Distributed IDP model

["Cahill, Conor P" <conor.p.cahill@intel.com>]

Title: Distributed IDP model

 

Thanks Conor.  I think you're saying step 2 should involve the IDP sending a SAML assertion to the CIA.  That makes sense conceptually, but it implies that IDPs must acquire & maintain SAML servers which partly negates the whole point of delegating SAML services to a CIA. 

What I was trying to say is that there is a whole bunch of information that is typically included in a SAML assertion that is issued for an SSO session.  If you delegate the creation of the asssertion to a second party, you have to get all that information over to the second party somehow.  One way is to send them the information in the assertion format.  Another way is to have a custom protocol for it.  

Instead I think what's needed is a lightweight SOAP request through which a IDP can ask a proxy to generate an assertion/artifact pair on its behalf.  The response would be a SAML artifact.  This request/response should ideally be part of the SAML standard protocols. 

I'm not sure how "lightweight" you can be if you're including all the IdP filled fields that can be in an assertion (essentially you end up sending over a duplicate of the structure of an assertion and at that point, why not  just use the assertion format).

 

Another point I would like to make is that an awful lot of thought went into the design of the system in SAML and much of it came from people with experience running large SSO implementations... we solved many issues related to a well oiled system.  Your question makes me think that you think you can get around many of these issues by delegating them to some other party; however, I'm not convinced that this can be satisfactorily accomplished without implementing full SAML betweek the IdP and the CIA. 

 

For example:

• Can the IdP (on it's own, or at the direction of the user) initiate a logout of the user?  If so you need the SLO protocols. 
• Similarly, if the RP initiates a logout, does the IdP find out about it from the CIA?
• How does the CIA get the NameID for the user (and does it get it in plain-text, or does the IdP already encrypt it for the Relying Party)?
• How does the IdP send out nameID changes (NameID Management) to the Relying Parties (is that through the CIA as well)?
• Who keeps track of an existing authentication session at the Relying Party?  The IdP or the CIA or both?

etc, etc...

 

I fear that any attempt to short circut these kinds of things opens up the potential for the creation of secutity holes.

 

As scott said, you can always treat the CIA as an internal implementation of the IdP (and therefore ensure that the interfaces exposed by the IdP/CIA fullfill the requirements of the SSO profile you're trying to implement).

 

Conor