Federated Authorization / XACML, OAUTH, TVE….

Federated Authorization – XACML, OAuth & TVE (T3I)

Convener: Ian Glaser & Paul Madsen

Notes-taker(s):

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Ian sets context. Problems facing higher ed, doing amazing things but SSO isnt enough.

What happens after you sign-in is the important stuff.

Federation has dealt historically with federated authentication. But knowing who the user is is less important than knowing what they can do.

Ian describes two different types of authorization policy – admin & runtime. Very different, typically different admins etc

Metadata?

Paul presented the XACML pattern for authorization

• PDP
• PEP
• PAP and policy store
• PIP

Who is asking or on whose behalf for authorization might be part of the authorization process

Where do you draw the enterprise boundary regarding the XACML decision pattern

Geroge Fletcher asserts that there is a some authorization in federated SSO – references Shib

Discussed federated runtime auth versions fedeated admin auth

• OAuth is an example of federated runtime auth with no federated policy admin (PAP and its output was mashed into code and comments)

Paul described TVEverywhere use case

• described SAML style TVE

Problem was back-channel conversation btw HBO and Comcast for example

• Eve asked why “channel subscription” wasn’t an attribute
• OAuth pattern for TVE

JWT includes the permissions that were established for customer

Eve claims there is a prosoal within UMA to handle this problem

• How you describe resources
• A pattern for describing scopes – mini-WSDL
• Authorization possibilities can be as finely grained
• Standardizes application semantics

Point raised that if you have a delegate chain of authoriation decisions I could make a local decision via a delegation assertion and that would be honored at the service-side

eduPerson entitlements

• Map groups to eduPerson entitlements
• We need SPs to pubish lists of entitlements
• Map strings from our side to your side

Guy from Stanford raises the issues of standarizing scopes

Bjorn of UnboundID asserts that this is more complicated. Raises issues of obligation. Provider can perform decision making or local decision made.

• must move beyond “you give me a name of a group and I’ll make a decision”

Further delegation of authorization – raised by Alan of HP

Eve drew a continuum of app versus remote service responsibilities

• Getting entitlements is the same a getting needed attribute in a sense

What happens when PDP and PEP are in truly different domains?

• What if they have conflicting or unalign goals?
• UMA has had these conversations and it sounds like this falls back to trust framework interop(?)

Description language missing. The RP is not describing what it is that they are doing. Definitely not machine readable.

Performance considerations. Hitting PDP every time is costly. Entitlements can be cached and might be more performant decision mechanism.

Does a trust framework have to establish semantic meaning?