What protocols should be supported for interactions between the PEPs within the relying party application and the PDP? OAuth? XACML?
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; what might make app integration easier?
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.
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)
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?
There are a number of software packages and defined processes with which rule-based access control could be implemented today
BGP as analogue
We need something like the Border Gateway Protocol (BGP) before we can ramp up support for distributed/federated authZ
How can we give people the ability to create and manage policies in an intuitive and easy way?
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
Change the containers, not the apps, then integration challenges are easier to deal with (Django/VOOT as an example)
Is the desired flow AA --> RP --> PDP or AA --> PDP --> RP?
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?
Identifiers not needed
There are approaches in which it is not necessary to map identifiers
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.
AuthN vs Attributes
The IdP has a dual function: 1) Getting some component to authenticate the user (local WebSSO or social2SAML gateway or whatever) and 2) garnering a set of attributes to be passed to the SP in the SAML assertion. It confuses the picture when we call the authenticating component an IdP. In other words, Brendan's approach is not "chaining IdPs": There's only one IdP and a multiplicity of authenticating components depending on which credentials the user has available. The site IdP can configure its attribute resolver to decorate its SAML assertion with additional site-maintained authZ information. The attribute resolver embedded in the Shib IdP is an Attribute Authority (AA), it's just packaged together. More often when we have talked about AAs, it's in the context of an SP aggregating attributes obtained from the IdP with additional information from an independent AA.