Title: RE: [security-services] ECP
Robert, can you clarify one of your statements in:
"... it might redirect the client to an SP's SAML logon
service which can interact with the ECP to initiate the profile."
Assuming an http redirection, does the PEP, in your discussion below, need to somehow pass or preserve the HTTP header defining "PAOS: ..., etc", or is it the responsibility of the ECP to resend them as part of the redirection? To put it another way, does the PEP need to be ECP-aware?
Thanks, Tom.
-----Original Message-----
From: Philpott, Robert [mailto:]
Sent: Wednesday, March 02, 2005 6:30 PM
To: Scott Cantor; Thomas Wisniewski
Cc: SAML
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.
