I am not sure on your position on this request. Are you suggesting to use the extensions element?
Current off-the-shelf implementations do not support this use case. As such we can only hope that future off-the-shelf implementations will work. IMO therefore the extensions element is not the way to proceed (at least not for a permanent solution).
Only being able to specify the required attributes on an authnrequest out-of-band through an AttributeConsumingServiceIndex is a limitation of the current SAML version. I am sure this was the only right choice back in 2005.
However, this choice should be reconsider for modern times. The number of (possible) attributes has increased and the attributes form the basis for ("claims" based) access control decisions. The latest (European) privacy requirements dictate we should never ask for more data except the data required to fulfil the current transaction. Also, users are required to provide consent.
My suggestion is to alter the AuthnRequestType as below and to define a new profile to facilitate this usecase in the next SAML version.
============
<complexType name="AuthnRequestType">
<complexContent>
<extension base="samlp:RequestAbstractType">
<sequence>
<element ref="saml:Subject" minOccurs="0"/>
*<element ref="saml:Attribute" minOccurs="0" maxOccurs="unbounded"/>*
<element ref="samlp:NameIDPolicy" minOccurs="0"/>
<element ref="saml:Conditions" minOccurs="0"/>
<element ref="samlp:RequestedAuthnContext" minOccurs="0"/>
<element ref="samlp:Scoping" minOccurs="0"/>
</sequence>
<attribute name="ForceAuthn" type="boolean" use="optional"/>
<attribute name="IsPassive" type="boolean" use="optional"/>
<attribute name="ProtocolBinding" type="anyURI" use="optional"/>
<attribute name="AssertionConsumerServiceIndex" type="unsignedShort" use="optional"/>
<attribute name="AssertionConsumerServiceURL" type="anyURI" use="optional"/>
<attribute name="AttributeConsumingServiceIndex" type="unsignedShort" use="optional"/>
<attribute name="ProviderName" type="string" use="optional"/>
</extension>
</complexContent>
</complexType>
============
Met vriendelijke
groet,
drs. Martijn Kaag
tel +31 (0) 88 01 20 222 | gsm +31 (0) 6 42 94 00 93 | skype
martijn.kaag-connectis
On Wed, Dec 10, 2014 at 8:29 PM, Cantor, Scott <> wrote:
On 12/10/14, 6:26 PM, "Martijn Kaag" <> wrote:
>
>The requirement to request attributes over a front end channel (either to
>facilitate consent or to allow for user interaction) if one that I
>encounter more often. A possible direction is to combine an AuthnRequest
>and AttributeQuery in one by extending
> AuthnRequestType with the zero or more <saml:Attribute>.
The reason the Extensions element was created in the schema was because
extending message types has no real benefit when it comes to getting off
the shelf code to work. If you have implementations that don't have any
customizability with respect to Extensions, that's basically a functional
limitation that has to be addressed if the code base has any hope of
longevity. OTOH, expecting SSO logic to handle arbitrary message types is
not realistic in practice.
So that's why a dedicated mechanism for extension of *existing* message
semantics was created.
TL,DR; extending AuthnRequest in the XML sense is a non-starter.
-- Scott
www.connectis.nl | Postbus 975 | 3000 AZ Rotterdam | +31 (0) 88 - 0120 222 | KvK 24444001
Connectis ontwikkelt een nieuw platform en zoekt ervaren software engineers.
Kijk op www.werkenbijconnectis.nl voor meer informatie.
Connectis, FederateNow™ en ZorgverlenerOnline zijn handelsmerken van Connected Information Systems B.V.
Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de geadresseerde(n) en strikt vertrouwelijk. Aan dit bericht kunnen geen rechten ontleend worden. Op het werk van Connected Information Systems B.V. zijn haar algemene voorwaarden van toepassing.
