Re: [saml-dev] SAML newbie question - do cross IdP trusts exist in SAML?

[Krishna Ganugapati <kganugapati@gmail.com>]

Hi,

 

More questions. I would appreciate it if you could give me more Yes/No clarifications..

 

1) Proxying

 

- In SAML proxying (per SAML-core) is the equivalent of Kerberos ticket referrals

 

- In Kerberos "proxying" is the S4U - a service principal can request tickets on behalf of a  user principal

2)Krb Referrals/SAML Proxying  

 

SAML proxying(referrals) are a backward chaining model [forgive the AI reference]. user contacts SP which refers him to the SPs IdP,  the SPs IdP refers the user to the user's IdP, the user's IdP issues a security token which the user presents to the SP's IdP which issues a security token which the user presents to the SP for service.

 

Kerberos referrals are a forward chaining model. Here I refer to the MSFT's AD intra forest or cross forest. User talks to own Kerb realm (AD domain) for a TGT, user present service FQDN to own Kerb realm for service ticket is instead issued  service ticket (TGT) for service's Kerb realm, user presents service realm TGT for service ticket to Kerb service, user presents service ticket to Kerb service.

 

 

3) On terminology (just a personal bias and I'm probably dating myself :-))

- When Scott informed me of proxying (and I read the SAML core yesterday), my first thought was that a SAML IdP talked to another SAML IdP directly - sort of like DNS server chaining as in an IdP proxies for another IdP. But my understanding now is that IdPs refer user clients to other IdPs (am I correct?). So SAML proxying is IdP referrals.

 

4) The SAML authentication request protocol does have semantics for referrals. How the IdP maintains referral information is an implementation detail and not speced out

 

5) Token caches

If the SAML authentication request protocol does understand referrals, do typical SAML clients maintain a SAML token cache similar to a  Kerberos ticket cache?

 

6) Has anyone deployed demonstrable examples of the multi IdP proxying

 

7) Simplicity

SAML relative to WS Security is simple. (Simple is good/elegant/orthogonal). I'd hope that the two systems are mutually exclusive, but it appears that the WS Security folk treat a SAML token as any other WS security token (which is understandable) and probably useful for bridging/interoperability between WS security systems and pure SAML systems. WS systems can consume and produce SAML tokens.

 

But one can build a native SAML based internet authentication infrastructure. Could you pls comment on the accuracy of this assertion?

 

8) Finally, is there the equivalent of an AS-REQ/AS-REP in SAML

 

In Kerberos, the AS-REQ/AS-REP is the bootstrapping mechanism. It allows you to generate your TGT based off  your password (or private key or any primary authentication credential).  From what I've read there is no equivalent of the AS-REQ/AS-REP. Getting the first token is another implementation specific detail - correct?

 

thanks

 

Krishna

 

 

 

 

On Mon, May 10, 2010 at 8:15 AM, Scott Cantor <cantor.2@osu.edu> wrote:

> TH: Yes this looks like a direct mapping of cross-realm TGTs concept with
> the IdP1/IdP2 scenario.  I think the relationship between an IdP and an SP
> is far more "richer" in contextual information compared to the KDC-to-KDC
> trust as defined in RFC4120. As Scott mentions, this also looks like
> proxying, which means it could make use of the S4U extensions of Kerberos.

Proxying in Kerberos is very different from IdP proxying in SAML. We're not
talking about impersonation of users, but relaying requests between IdPs to
isolate trust relationships.

-- Scott



---------------------------------------------------------------------
To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: saml-dev-help@lists.oasis-open.org