AuthZ Thread Summary

1

Protocols

What protocols should be supported for interactions between the PEPs within the relying party application and the PDP? OAuth? XACML?
What protocols should be supported for interactions between the PDP and the PIPs? What if the PIP is Grouper?

2

Integration

It seems too complex to insist on call-outs to a PDP from each point within an application that needs to enforce some form of access control

3

Groups

Aren't groups enough?  That is, practically speaking, an app can base most of its access control decisions on a set of group memberships that are made available in the SAML assertion at the time the user shows up.

4

Entitlements

An alternative to groups (which tend to put access control logic at the application end) is entitlements (which tend to put access control logic at the IdP end)

5

Rules

Are there situations in which it is beneficial to go beyond groups and entitlements and manage access via policy rules that are evaluated at the time the user seeks to perform a particular action on a particular resource?

6

Prior art

There are a number of software packages and defined processes with which rule-based access control could be implemented today

7

BGP as analogue

We need something like the Border Gateway Protocol (BGP) before we can ramp up support for distributed/federated authZ

8

Policy Management

How can we give people the ability to create and manage policies in an intuitive and easy way?

9

User issues

How do we let users know what resources they have access to? what the RP/SPs policy is? In general how to give the user appropriate control over the process

10

Containers

Change the containers, not the apps, then integration challenges are easier to deal with (Django/VOOT as an example)

11

Flows

Is the desired flow AA --> RP --> PDP or AA --> PDP --> RP?

12

Identifiers

If the IdP is not the sole source of access control information (i.e., if an independent PIP carries relevant info), how do you correlate the identifier from the IdP with the identities known in the PIP repository?

13

Identifiers not needed

There are approaches in which it is not necessary to map identifiers

14

Privacy

In situations where correlation is needed to link IdP identifiers to PIP identities, it is common to rely on ePPN; This raises user privacy concerns. Sites that have this concern tend to favor evaluating the authorization rules at the IdP and passing only entitlements (or group memberships) to the SP.

15

AuthN vs Attributes

At sites that support, say, authN via social providers, the site IdP can configure its attribute resolver to decorate its SAML assertion with additional site-maintained authZ information; In other words, from the SP perspective the site IdP appears to be doing both AuthN and attribute assertion.