Subject: RE: [security-services] ECP
All, thanks for your explanations. I'm glad to hear it works in the manner as you described. It is much more manageable to provide a solution.
I have 2 other related ECP questions:
1. Related to conformance -- a conformant IDP must support an AuthnRequest profile using the HTTP-Redirect binding based on the doc (this is explicit in the conformance doc). It must also however support the SOAP binding (which is implied in the conformance doc based on the requirement for ECP).
2. In the Binding spec, line 732, related to how the ECP conveys the AuthnRequest to the IDP. It says the ECP does this "...using a modified form of the SAML SOAP binding with the additional allowance that the identity provider may exchange arbitrary HTTP messages with the ECP...." Does the phrase "modified form" correspond with the additional allowance to exchange messages or is it meant to imply something else in addition to being able to exchange messages?
From: Robert Aarts [mailto:email@example.com]
Sent: Thursday, March 03, 2005 2:15 AM
To: Philpott, Robert
Cc: firstname.lastname@example.org; Thomas Wisniewski; SAML
Subject: Re: [security-services] ECP
lots of mail on this topic.... If it is of any help: in my view Scott's
and Robert's analyses/interpretations are correct.
Yes, an ECP (a LECP in Liberty) is required to support HTTP, hence it
MUST NOT barf on receiving a (plain) 302 redirect. A proper/typical ECP
implementation will send its ECP header along with every HTTP request,
it will typically not know if the URL is protected or not (note that it
is conceivable to do a ECP that sends the header only to a few sites,
but that's up to the ECP; likewise one could do a ECP that does send the
header everywhere except to some site). The (L)ECP implementations that
I've done all sent the header everywhere.
And as Scottt noted: the ECP profile "kicks in" only when the ECP
receives a response with the PAOS mime-type and the appropriate message
in the soap:Body.
BTW/FWIW cookies are something to be careful about in ECP deployments.
This was/is especially an issue when it is a EP, as the EP is stepping
in for the browser. When e.g. the IDP responds with a login page, the
browser will think it came from the SP, so better not set a cookie on
that first page. Some ECP implementations take care of this, but
probably not all.
In Liberty the MTI for LECP was there to ensure that if somebody shows
up with an (L)ECP at a site they will get served in an ECP aware manner.
An ECP gives an end user control over the logon process, e.g. what IdP
to go to. At the same time ECP is advantageous to SPs too, it solves
very well the "where is the IDP" issue. I personally feel that (L)ECP
should be MTD, mandatory to deploy unless you know that there will be no
ECP ever visiting your SP. But I would say that a *deployment* is not
compliant if it doesn't do ECP when a UserAgent comes along that send
the header. To ensure that deployments can be compliant in this manner,
Liberty decided to make LECP a MTI feature.
>The PEP itself MIGHT be ECP-aware, but IMO it should not HAVE to be
>ECP-aware. In the example I was describing, I'd like to have my COTS
>WAM product (e.g. RSA ClearTrust :-)) protecting web server resources
>for any type of HTTP-based web access. These PEP's typically have a web
>agent that intercepts requests for resources and requires the user to be
>logged in or they don't get through. If not logged in, they typically
>redirect the user to the WAM product's local logon service. To
>SAML-enable such an environment, I would like to just configure this PEP
>to send the clients to an ECP-aware SAML logon service instead of the
>local logon service. In our case, we do this through simple
>configuration options. This means we don't have to directly SAML-enable
>or ECP-enable the PEP itself. If the SAML logon service detects a
>standard browser client, then it would take care of IDP selection and
>starting the standard Web SSO browser profile. If it detects an ECP
>client, it jumps into the ECP profile logic.
>I agree with Scott that it's the client's responsibility to continue
>passing the PAOS header info wherever the client goes or gets sent.
>As long as the PEP can just ignore a PAOS header if it receives one from
>a client (i.e. it doesn't reject the client), then these existing PEP's
>can be integrated with SAML environments.
>At least in the Web Access Management (WAM) arena, that's how we see
>Now, of course, we've not yet actually had access to a real live ECP
>client to try this stuff out... so if any of those client developers are
>out there, please pipe in here...
>Senior Consulting Engineer
>RSA Security Inc.
>>From: Scott Cantor [mailto:email@example.com]
>>Sent: Wednesday, March 02, 2005 9:08 PM
>>To: 'Thomas Wisniewski'; Philpott, Robert
>>Subject: RE: [security-services] ECP
>>>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?
>>I think it's the client's responsibility, as it's the PAOS-enabled
>>We should ask one of the client developers, but I bet their devices
>>always send the header if they're configured to support the service.
>To unsubscribe, e-mail: firstname.lastname@example.org
>For additional commands, e-mail: email@example.com