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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: Re: [security-services] ECP


Hi all,

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.

greetings, Robert

>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
>this working.
>
>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...
>
>Rob Philpott
>Senior Consulting Engineer 
>RSA Security Inc. 
>Tel: 781-515-7115 
>Mobile: 617-510-0893 
>Fax: 781-515-7020 
>mailto:rphilpott@rsasecurity.com
>
>
>  
>
>>-----Original Message-----
>>From: Scott Cantor [mailto:scantor@wideopenwest.com]
>>Sent: Wednesday, March 02, 2005 9:08 PM
>>To: 'Thomas Wisniewski'; Philpott, Robert
>>Cc: 'SAML'
>>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
>>    
>>
>device.
>  
>
>>We should ask one of the client developers, but I bet their devices
>>    
>>
>just
>  
>
>>always send the header if they're configured to support the service.
>>
>>-- Scott
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: security-services-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: security-services-help@lists.oasis-open.org
>
>  
>



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