Re: [security-services] Dutch eID Preso follow up. RE: Proposed Minutes for SSTC Call (Nov 25, 2014)

[Martijn Kaag <martijn.kaag@connectis.nl>]

> The requirement for dynamic attributes had been claimed in the past e.g. [1][2][3], but I have not seen anybody to name a specific example where it actually 

> would make sense. As you require a large number of permutations, I would be interested what the concrete business case is.

We have a federation with 1000 service providers each offering between 2 and 25 different services. Many services are cross-organizational, i.e. they span multiple service providers. Authorisation is based on attributes, e.g. the user needs be entitled for service "Amazon" and should be allowed to make purchases up to 1000 euro. Depending on the context (e.g. which purchase the user is about to make), the SP will need different combinations of attributes to make its authorisation decision (many will use XACML do evaluate this decision, but that is outside of the scope of this discussion).

For a portal, the SP may ask it the user is authorized for service A to Z and only show the services that the user is entiteld to (e.g. only show A, B and E).

The SP cannot ask for all attributes and / or all roles as 99,9% of this information does not apply to the SP. Hence the need to make request for specific attributes (e.g. service A to Z). This is still quite manageable in an isolated SP-IdP connection. We can define various attribute contracts and use AttributeConsumingServiceIndex to select one. A typical SP will not use no more than 10 different attributes and just a couple of combinations.

But: we also act as a proxy (Broker). Our broker connects to 1000 SPs and delegates to 10 IdPs. There are other Broker as well. So on our Broker to IdP connections we have thousands of different combinations of attributes. The AttributeConsumingServiceIndex (as a short) cannot hold this number plus the process of exchanging metadata is tedious.

> Data minimization has been given as a reason in the past, but that should be challenged. Optional attributes are against strict data minimization - the minimal data set
> is specified by mandatory attributes.

In a federation, mandatory attributes may be different per service provider and various (combinations of) service providers will define their own attributes. This becomes an issue when proxying.

 

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 Thu, Dec 11, 2014 at 9:11 AM, Rainer Hoerbe <rh@identinetics.com> wrote:

On 12/9/14, 10:07 PM, "Martijn Kaag" <martijn.kaag@connectis.nl> wrote:

> I agree, but there are several challenges:
>
> * They need to communicate the requested attributes at runtime. For
> several reasons, AttributeConsumingServiceIndex is insufficient (there
> may be more than
> 65535 different combinations of requested attributes).

The requirement for dynamic attributes had been claimed in the past e.g. [1][2][3], but I have not seen anybody to name a specific example where it actually would make sense. As you require a large number of permutations, I would be interested what the concrete business case is.

Data minimization has been given as a reason in the past, but that should be challenged. Optional attributes are against strict data minimization - the minimal data set is specified by mandatory attributes.

Another reason might be the limitation of products to map different applications to multiple SPs, resulting in a lengthy list of ACS in a single SP spanning all applications of a site.

[1] TAS3: http://www.zxid.org/tas3/anrq-index.html (Sampo proposing an AttrQuery embedded in an AuthnRequest)
[2] STORK's SAML profile (D5.8.3b Interface Specification) includes a < stork:RequestedAttribute> in <saml2p:Extensions>. On inquiring on the use case for it it turned out that this was included only to be on the safe side, not for a concrete requirement.
[3] https://spaces.internet2.edu/display/InCCollaborate/SP+Attribute+Requirements lists the AuthnRequest extension as an alternative to metadata.


- Rainer

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.