RE: [saml-dev] Distributed IDP model

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

Title: Distributed IDP model

 

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).
[McCormick, Mike] You may be right.  Does SAML protocol define a standard request=assertion / response=artifact type of message?  

No.  In SAML 2, an artifact represents a message, not an assertion (of course, the message that the artifact represents may be the delivery of an assertion).

 

SAML 2 does have something that is close: the ECP AuthnRequest. 

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. 
  [McCormick, Mike] This is not an issue for the community in question because there are no coordinated logoff requirements. 
• Similarly, if the RP initiates a logout, does the IdP find out about it from the CIA?
  [McCormick, Mike] See above. 
• 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)?
  [McCormick, Mike] The user name (and possibly other attribute data) will be passed on the call from IDP to CIA in step 2. 
• How does the IdP send out nameID changes (NameID Management) to the Relying Parties (is that through the CIA as well)?
  [McCormick, Mike] This is not an issue for the community in question because naming is based on permanent UUIDs. 
• Who keeps track of an existing authentication session at the Relying Party?  The IdP or the CIA or both?
  [McCormick, Mike] This is not an issue for the community in question because there are no coordinated session mgmt requirements.  

 I realize that you have apparently good answers to the examples of potential issues  and perhaps have them for all possible sets of issues.  I just am trying to piont out that you need to do a full security analysis of any changes you make in the protocol.

I fear that any attempt to short circut these kinds of things opens up the potential for the creation of secutity holes.
[McCormick, Mike] You may be right but I'd like to see an example that's applicable to my particular circle of trust.  I believe there are applications and communities for which this distributed IDP model can be safely implemented.  It would be great if SAML supported us. 

There are ways to do this that work with SAML.  For example, your IdPs could proxy through the CIA so IdP sends an unsolicited authNResponse that includes RelayState indicating the ultimate relying party and the CIA then sends the artifact to the relying party.

Another is that the relying party sends an authnreqest to the CIA which then sends the authnRequest to the IdP and the bounce back.

Another is that the relying party sends an authnRequest to the CIA and the CIA proxies the authentication across a backchannel to the IdP (so the CIA is a man in the middle, but he is in any of type of solution.

 

These all can work with the SAML protocols off the shelf. 

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).
[McCormick, Mike] Yes that's exactly what we'll be forced to do if the SAML paradigm insists on viewing the IDP and CIA as one logical entity and doesn't provide any standard interfaces for their "internal" information exchanges.  

SAML does not insist on that.  However, you can create a specific enough set of requirements that would force this to be that way.  For example, you've said you want the Relying party to know the original IdP (not the CIA), but the CIA can't act as that IdP (doesn't have the IdP's keys) so you would likely need to add some data (perhaps an assertion signed by the IdP)  and perhaps the best place would be in the <Advice> element.

 

Conor