OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]