RE: [saml-dev] Use of ECP Profile

["Conor P. Cahill" <concahill@aol.com>]

Jean-Noel Colin wrote on 10/27/2004, 9:26 AM:

I think your idea of having SP-A request a token that it then uses to access SP-B is the simplest and most efficient way to design my system. Doesn't this sound a bit like a Kerberos system, where the IdP would be a Ticket Granting System?

Yes.  Way back
when we started thinking of how to do this stuff (a few years ago, but
it seems like much longer) we took a strong look at kerberos and
decided against it for several reasons, the primary being that it is
not designed around a system where the method used to authenticate the
user is part of the authentication request and response (it is more of
an on/off -- is the user authenticated or are they not authenticated
model).   So we looked toward SAML to provide a much more robust
environment for security tokens.

I drew a diagram that (I hope) represents these interactions. Could you please check if it matches what you have in mind?

Yes it does.

Regarding the request for token, which type of protocol is this? Is it an 'AuthnQuery' with subject X? Is it another protocol? The response should then contain AuthnAssertion certifying that user X has been authenticated using mechanism Y.

This is another
protocol that doesn't currently exist in SAML (as far as I know).  In
Liberty, we defined an SSO service within the Authentication Service
that can be used to obtain tokens as described.

Wouldn't it make it more generic if before calling SP-A, the ECP requests a token from IdP to access SP-A? We would then have a generic call mechanism that would be: 1. get token to access service 2. access service

In case of service chains, couldn't SP-A call SP-B with the token it has been called with? So User X accesses his User Environment, which requests a token to access SP-A from IdP, then call SP-A with that token; if SP-A needs to call SP-B, it takes the token it received from User X (which it trusts) to invoke SP-B. What do you think?

In liberty we
defined an entity (LUAD) which is an intelligent client that actively
particpates in authentication and SSO transactions (for example, AOL
has a radio client that uses the authentication service and Discovery
service to obtain tokens (SAML Assertions) to access the radio service
for that client).  This is essentially a non-browser environment
although you will hear others (Scott Cantor being one of them) that
believe that this type of functionality (active
partiticipation/knowledge of SSO environments) being added to base
browsers )

A final question: do I really need an ECP here?

From what I've
seen of your examples, I would say you just need a plain jane browser
-- the ECP isn't really adding any value.

Conor