[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] ECP
> > > One other question on the ECP's initial request -- the ECP > > does require that the response (first response) back from the > > SP to be the Saml AuthnRequest using PAOS. Is that correct? > > Hmmm, I'd think that the point is to eventually initiate the profile, but > until you do, you're just "doing stuff with the client". > > > I.e., the SP cannot do any additional interactions that the > > ECP would be able to handle (e.g., an HTTP 302 redirection > > from the resource protecting filter to a saml requester > > service) where the eventual response would be the Saml > > AuthnRequest using PAOS? > > I can't see how that would be illegal, given that the client really isn't > "doing the profile" until it gets back the PAOS envelope. As long as the > HTTP request that results in the PAOS response contains the headers that > indicate the client is prepared to do the profile... > > Anyway, that's how I would read it, dunno about anyone else. I did a lot > of > work on the exact headers flowing around, but the profile by and large is > just work done by the original author who mapped the ID-FF profile to > PAOS, > so I'm not exactly the "bible" on this. [RSP] This is also how I read this. As far as I know, it is assumed that the ECP client can be expected to know how to handle things such as redirects (and cookies, etc?). Thus, a deployment might use a generalized PEP (e.g. a COTS web access management product) to sit in front of protected resources. If the PEP detects an unauthenticated client request, it might redirect the client to an SP's SAML logon service which can interact with the ECP to initiate the profile. Eventually the ECP client will be redirected back to the protected resource with information (perhaps a cookie?) that permits the PEP to understand that the client is now authenticated.