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 profile question


Doh, thanks Scott.   Thanks for making me feel dumb ;-) I must have been
asleep on the call where we talked about that.  I see it now.  I
actually did check the errata but somehow missed PE35 which is where
this issue is discussed.  I saw PE22 about the ASC rather than ACS but
glossed over 35.  Wouldn't it be nice if we had a red line version of
the spec and didn't have to cross reference a 40 page errata document
all the time... :)

Unfortunately I think the value in the errata is still broken.  PE35
changes the value of the responseConsumerURL on page 29 line 964 from 

http://identity-service.example.com/abc

to

https://ServiceProvider.example.com/AssertionConsumerService


but the value of the AssertionConsumerServiceURL in the example on page
30 line 1031 is

https://ServiceProvider.example.com/ecp_asserton_consumer

and according to lines 1012 - 1021, 

"AssertionConsumerServiceURL [Required] 

Set by the identity provider based on the <AuthnRequest> message or the
service provider's metadata obtained by the identity provider.

The ECP MUST confirm that this value corresponds to the value the ECP
obtained in the responseConsumerURL in the PAOS Request SOAP header
block it received from the service provider. Since the
responseConsumerURL MAY be relative and the AssertionConsumerServiceURL
is absolute, some processing/normalization may be required.

This mechanism is used for security purposes to confirm the correct
response destination. If the values do not match, then the ECP MUST
generate a SOAP fault response to the service provider and MUST NOT
return the SAML response."


It seems like this example would still require the ECP to send a SOAP
fault response to the service provider.  No?

Why have the AssertionConsumerServiceURL at all?  Why not just have the
ECP always deliver the response to the responseConsumerURL?

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Wednesday, February 01, 2006 7:32 PM
> To: Brian Campbell; security-services@lists.oasis-open.org
> Subject: RE: [security-services] ECP profile question
> 
> > Regarding the ECP SSO profile - I'm a bit confused about the
> > usage of the responseConsumerURL attribute in the PAOS header
> > sent from SP to ECP and the AssertionConsumerServiceURL
> > attribute in the ECP response header sent from the IdP to the
> > ECP.   I've included the relevant sections (that I could
> > find) of the profiles spec below.
> 
> You forgot the errata. ;-)
> 
> > As I understand it, the ECP sends a message to the SP at the
> > location specified in the responseConsumerURL _only_ in event
> > that there is some error condition.  Otherwise the value of
> > the responseConsumerURL attribute is used only for the ECP to
> > confirm the value of the AssertionConsumerServiceURL it got
> > from the IdP by comparing the two.  And the value of the
> > AssertionConsumerServiceURL is where the ECP will deliver the
> > SSO response.
> >
> > Do I have that correct?
> 
> Yep.
> 
> > Am I missing something here?  Was this just an oversight (and
> > perhaps errata item) or were these values intentionally set
> > that way in the example?
> 
> It's already in errata, I believe.
> 
> -- Scott
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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