use of Scoping element in AuthnRequest to assist with front-channel attribute aggregation

[Scott Koranda]

Hi,

To complete the thread I will reply here but to respect the use of
this mailing list
I ask that any follow up be sent to me directly. Thanks.

>
> I would be interested to know how this system
>
> a) determines which attributes are required from the AA

I do not know.

> b) determines which attributes are required from the IDP

I do not know.

> c) can use targeted ID with the AA when it is supposed to be shared
> between an IDP and SP. If two SPs have different targeted IDs for the
> same user from the same IDP, then how can the AA work properly?

It is designed specifically to "work around" (my words) the problem of
using the Shibboleth SP back-channel simple aggregation which requires
the use of a non-targeted globally unique ID like ePPN or similar.

The flow begins with a standard SP-initiated SSO flow. After that part
of the flow is complete the browser has a session with an IdP and an SP and
presumably the IdP has sent the SP a targeted (and most likely opaque) ID.

The SP then initiates the second part of the flow by sending the <AuthnRequest>
with the <Scoping> element to the attribute authority/IdP proxy. The AA/proxy
knows from the <Scoping> content which IdP the subject has a session
with and causes
a new SSO flow between the AA/proxy and the IdP. This causes a second targeted
ID to be sent to the AA/proxy (playing, to some extent, the role of an
SP here).

At that point the AA/proxy uses the second targeted ID to look up
attributes about the subject (previously recorded during
another out-of-band process like registration or enrollment).

Those attributes are then sent back to the SP. The aggregation of the attributes
from the IdP and the AA/proxy happens at the SP.

In this way the SP is able to obtain attributes about the subject from
the AA/proxy even though
it only ever received a targeted ID from the first IdP.

I should also mention that other people have apparently described and
even implemented "front channel attribute aggregation" flows
before. I am simply learning about them now myself and wanted input on
the details of this specific implementation.

Thanks,

Scott K

> Or is
> this now an untargeted globally unique non-privacy preserving ID?
>
> regards
>
> David
>
> On 25/11/2013 16:52, Scott Koranda wrote:
>> Hello,
>>
>> If this is not an appropriate question for this list I would be
>> grateful if you could point me to the correct list.
>>
>> I have come across some work on so-called "front-channel attribute
>> aggregation" that is using a <Scoping> element as part of an
>> <AuthnRequest> element to include the entityID of an IdP already used
>> to authenticate the subject. The entityID for the IdP is included in
>> an <IDPList> element.
>>
>> The <AuthnRequest> is sent from the SP to an "attribute authority"
>> that is then using the entityID of the IdP to cause the browser to go
>> through another authentication with the IdP but this time sending the
>> assertion to the attribute authority, which then uses the targeted ID
>> sent by the IdP to the attribute authority to look up attributes for
>> the subject.
>>
>> The <AuthnRequest> looks something like this:
>>
>> <samlp:AuthnRequest
>>   xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>>   AssertionConsumerServiceURL="https://myservice.edu/some/acs"
>>   Destination="https://attribute.authority.edu/some/url"
>>   ID="_b8f5f2a1361f90a4611caa60b908dc28"
>>   IssueInstant="2013-11-21T11:59:30Z"
>>   ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
>>   Version="2.0">
>>   <saml:Issuer
>>     xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://myservice.edu</saml:Issuer>
>>   <samlp:NameIDPolicy AllowCreate="1"/>
>>   <samlp:Scoping>
>>     <samlp:IDPList>
>>       <samlp:IDPEntry ProviderID="https://some.idp.edu"/>
>>     </samlp:IDPList>
>>   </samlp:Scoping>
>> </samlp:AuthnRequest>
>>
>> Questions:
>>
>> 1) Is there any defined profile that addresses this type of
>> front-channel attribute query or aggregation?
>>
>> 2) Any comments on the use of an <AuthnRequest> to the attribute
>> authority to solicit attributes about the subject?
>>
>> 3) Any comments on the use of the <Scoping> element to signal to the
>> attribute authority to which IdP to direct the browser to complete the
>> assertion of a name identifier from the IdP to the attribute
>> authority?
>>
>> Thank you for your consideration.
>>
>> Cheers,
>>
>> Scott K
>> --
>> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
>>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net