Front-channel Attribute Aggregation is one of many data access API methods that needs to be explored in the Virtual Organization track of the GÉANT3 JRA3 Identity Federations task.

Participants:

• ...

0.1 Introduction

The main complexity in using the back-channel SAML 2.0 Assertion Query Profile for attribute aggregation is related to establishing cross-service syncronized identifiers for the user.

Protocol messages exchanged front-channel benefit from the fact that they can be implicitly referring to the current user session, and therefore not neccessarily including a explicit reference to the user with a shared identifier.

If the AttributeQuery protocol saml2-core is used with a front-channel binding, such as HTTP-REDIRECT or HTTP-POST saml2-bindings, the implicit refence to the current user could be exploited. Unfortunately, there is no existing defined SAML 2.0 profile saml2-profiles, where the AttributeQuery protocol is allowed to be used with front-channel bindings. This raises a need for a new SAML 2.0 profile.

0.2 Task 1: Write a new SAML 2.0 Front-channel AssertionQuery Profile

Write an alternative to the current Assertion Query Profile saml2-profiles, where the request and response is sent using front-channel bindings, such as HTTP-REDIRECT, HTTP-POST and Artifact.

Both the request and response should be allowed to be sent without embedding any explicit user ID.

This involves a challenge as the AttributeQuery protocol element extends the SubjectQueryAbstractType abstract element, which requires the inclusion of a <saml:Subject> in the request. This is in contrast to the <samlp:AuthnRequest>, which extends the RequestAbstractType and does not require the inclusion of a <saml:Subject>. The omission of the <saml:Subject> might have been the most preferrable way of implicitly referring to the current user.

Work should be made to investigate the most appropriate way of referring to the current user with a <saml:NameID>, <saml:BaseID> or <saml:EncryptedID>. Examples that should be investigated is:

• Using an empty <saml:NameID>
• Using an empty <saml:BaseID>
• Using an encrypted <saml:EncryptedID> targeted to the Identity Provider.
• Creating a new transient <saml:NameID> to be used with the communcation with the VO platform.

• Re-using the <saml:NameID> received fromt the Identity Provider, adding a subject confirmation element.

   <saml:Subject>
       <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
          1234</saml:NameID>
       <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
   </saml:Subject>
  

0.3 Task 2: Implementing the front-channel attribute query profile in SimpleSAMLphp

The more recent SimpleSAMLphp code includes a SAML library that supports the Attribute Query protocol. The library is located in lib/SAML2.

A proof of concept attribute authority can be used as a reference, and is located in modules/exampleattributeserver/www/attributeserver.php. An example client is located in www/example-simple/attributequery.

• Task 2.1: Create an attribute authority, that uses a configured authentication source, such as in exapmple the SAML:SP, and the replies with the attributes.
• Task 2.2: Create a test page that retrieves attributes from a configured attribute authority, getting endpoint data from metadata.
• Task 2.3: Create an authentication processing filter that can be executed in order to retrieve attributes in a Service Provider immediately after login.