RE: [saml-dev] Use of ECP Profile

["Jean-Noel Colin" <jean-noel.colin@oxys.be>]

Conor,

 

I agree, my proxying mechanism adds extra complexity that is not really useful.

 

Note that the user environment (here the ECP) is not a browser, but is a server-side component, that the user access through a browser.

 

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?

 

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

 

Basically, the first AuthnRequest that is issued by SP-A is finally processed by IdP, which will return a AuthnAssertion, saying that 'user X has been authenticated using mechanism Y)

 

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.

 

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?

 

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

 

Thanks a lot, I think I'm getting closer.

 

Jean-Noel

---

From: Conor P. Cahill [mailto:concahill@aol.com]
Sent: mercredi 27 octobre 2004 14:40
To: Jean-Noel Colin
Cc: saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] Use of ECP Profile

Jean-Noel Colin wrote on 10/27/2004, 8:17 AM:

Conor,

 

I thought that the proxying mechanism defined in SAML specifies that the proxying IdP sends a AuthnRequest to the another IdP, and receives the Response from that IdP that it then relays to the original requester.

THis is yet another environment that we have not 
been discussing previously.  A Proxying IdP (which is not an ECP),  
would act as an SP to the original IdP and then as an IdP to the subsequent SP, 
so in your case, you have an IdP, you have SP-A (which you now sound like you 
want to act as a Proxying IdP), and you have SP-B.   

The only 
way for this to work is for the user agent (ECP in this case) to be transferred 
to SP-B.  SP-B then initiates an authentication with it's IdP (SP-A in this 
case, which we'll call IdP-A) by redirecting the ECP to IdP-A with an 
AuthnRequest.  IdP-A then acts as an SP (SP-A) and  redirects the ECP 
to the original IdP to get an authentication.

In both cases, the ECP 
could deal with figuring out the location of the IdP, but the ECP still has to 
be pointed to the various participants in the transaction.  

In 
addition, in a Proxying IdP model, SP-B has to accept assertions generated by 
SP-A (acting as an IdP).  Which is very different from your original model 
of SP-B getting a token from the real IdP.

So woulnd't itwork if all my services are able to act as proxying IdP? Only the user's main environment would be an ECP, and each service  would implement a 'proxying IdP'  to make sure that it can proxy any Authnrequest issued by any other service it calls.

You still have the issue of the 
ECP.  You also have the issue of the SP-B trusting SP-A's assertions.  
You are also having one entity emulate both an ECP and an IdP at the same 
time.

Regarding the Disco Service, we could do without (at least in a first phase) if all security mechanisms between the project modules are standardized, i.e. if we know upfront what type of authentication will be required and implemented; is that correct?

As I said, the basic thing you need is the 
Authentication Service where SP-A can send a message to the IdP asking for a 
token for SP-B.  (and typically including the token that SP-A received from 
the IdP for SSO at SP-A).  If you have pre-defined locations of SP-B and 
you have pre-defined security mechanisms and you know up front that the service 
is at SP-B, then you can just get the token and go with it.

However, I reckon that such a Disco Service would have an added value if we develop our services in a generic way, so that each of them can advertise different security requirement.

Yes, and you can remove the dependency on 
knowing where SP-B is, on knowing that SP-B is the provider of that particular 
service (in other words, it reduces the amount of pre-defined data that you have 
to have).  Note that you can still use the DS with pre-defined behavior 
(e.g. you can pre-define the data in the DS so that it doesn't really have 
dynamic data within the service).  That will allow a current implementation 
with pre-defined data that is easily extended into dynamic data when the DS is 
upgraded without impacting the SPs (this is what AOL did with our first DS 
implementation since we knew the information about the initial service providers 
but we didn't want to hard-code that into clients (for many 
reasons)).

Conor

Service Chain.jpg