[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] Use of ECP Profile
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.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.
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.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.
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.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?
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)).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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]