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

["Scott Cantor" <cantor.2@osu.edu>]

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

You're mostly correct on all points.

> 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.

That's true of browser SSO, but that isn't the only use case. STS-like
scenarios in which one might acquire assertions could be forward chaining.
 
> 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.

Again, true for SSO, not necessarily other cases.
 
> 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?

If the client is not a browser and is dealing with longer-lived assertions,
then probably. That's nothing to do with proxying though.

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

I believe there are common federation scenarios that do so.

> 7) Simplicity
> SAML relative to WS Security is simple. (Simple is
good/elegant/orthogonal).

Many would beg to differ and claim both are too complex. The lesson is that
words like simple and lightweight usually don't belong in meaningful
technical discussions, they're marketing terms and subjective opinion.

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

Yes, it's possible. It's also possible to package and connect SAML
assertions with non-SAML credentials by way of SubjectConfirmation and thus
use SAML to bridge arbitrary (or future) token formats. Which is to say that
WS-Trust's "advantage" is not one.

> 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?

An AuthnRequest is such a message. The issue is that unlike Kerberos, the
binding defined for active clients making use of the message (SOAP) is
agnostic about authentication and allows for many different approaches.
Thus, profiling is required to interoperate.

-- Scott