Consent-Informed Attribute Release for SAML/OIDC at Scale

Consent-Informed Attribute Release (CAR): Serving SAML and OIDC/Oauth

Tuesday 2I

Convener: Ken Klingenstein

Notes-taker(s): Judith Elaine Bush

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

Topics

• CAR basics

– Useful related products–attribute taxonomy

• CAR in multi-lateral federated SAML families

– Services for attribute release and consent – Informed content gathering and use – Unexpected outcomes

• CAR and the Oauth world – Services for permission setting and consent – Informed content gathering – Next steps – Possible unexpected outcomes

Consent-Informed Attribute Release (CAR)

• A system of components that serves attribute release and consent needs across all protocols – OIDC and OAuth as well as Shib/SAML.

– Integrates organizational and individual choices for attribute release

– Support for user consent decisions that are informed, effective, revocable, accessible, etc.

• Catalyzed by NIST NSTIC grant and now becoming an Internet2 open-source TIER component.

• Includes UI/UX, enterprise and individual attribute release policy stores, notification and event services, individual and organizational admin interfaces, all accessed through the CARMA API

• UI/UX well researched, well-designed and well-implemented. Includes

• –  Device and browser independent. Device adaptive-works well with mobile apps. I18n and locale

• –  Fine-grain controls on attribute release (down to value level of multi-valued attributes), explanations, reconsent options, friendly names and values, etc.

• –  User self-serve for bulk management, revocation,e tc.

• HA, packaged in Docker containers. Scheduled to go through alpha/beta/1.0 over the next 6-12 months.

Consent-Informed Attribute Release Manager (CARMA)

• The CARMA API is the entryway for applications and users to manage attribute release; applications call CARMA to get consent and attributes or information items.

• CARMA is instantiated as: – a published API (ICM API) - ICM_July12_2016.yaml – HAcodeasaVMwithinaDockercontainerthatimplementstheAPI

• Includes UI for end-users in a variety of use cases (in-line, off-line, persistent) and management UI for end-user self-service, policy administrators, configuration, etc.

• Includes admin and super-admin consoles

What is Informed Content

• The fuel that drives effective and informed user consent decisions

• Limited, though extensible sets of marks, assessments, policies, etc. that are part of the UX

– Additional user-centric information feeds

• Vetted, self-asserted, reputation systems, etc

• Far-reaching insights - https://arxiv.org/abs/1608.05661

Attribute taxonomy

• Analyzes key characteristics of attributes and how to present and manage them

• https://docs.google.com/document/d/13cFEpkaerCgit- aPPek2VZBFLwp7XhixZz0MHuZkdx8/edit

Status and Next Steps

• The core functionality of CAR code is complete

• Enhancements (policy editors, user-managed triggers for reconsent, improved admin interfaces, etc) await

• Being packaged now to TIER standards

• A cycle of code release versions and bug fixes etc awaits

Using CAR in a multi-lateral federated SAML family

• Attribute release is a major problem for R&E federations primarily due to attribute- retentive institutions wanting user consent.

• CAR is readily integrated into the Shibboleth IdP v3, with it being called for institutional attribute release policy editing and as the decision point for attribute release per transaction

• CAR gathers informed content from a variety of sources

Unexpected Outcomes

• Consistent, informed user experience across a variety of platforms and protocols

• Integration of institutional and individual attributes

– Location

– Emergency contact and medical information

– Personalschedules

• Managing consent across applications and consent as a service

• Providing new options for accessibility

• Extending organizational attribute release policy from directory/IdP to other systems of

record with bio-demographic attributes.

• Creates institutional policy repository and service for attribute release

Integration Of OIDC With CAR

CAR can serve as a

• policy decision point (PDP) and policy store for an OIDC authZ server

• point of administration for end user self-service of their consent policies

• point of administration for an IT admin CRUD’ing institutional policies (if they exist)

• policy store only

We talk about each of these.....

Policy Decision Point (PDP) + Policy Store Option

• CAR has its own REST endpoints for returning decisions about a given user, RP, and set of scopes and claims -- called “info items” in CAR documentation.

– CAR relies in this case on the AS to authenticate the user (and send CAR the id in a JWT)

• CAR can operate as a PDP (& policy store) for an OIDC AS in both the user present, user offline, and “prompt = none” cases.

• If the user’s policy choice is “ask me” for even a single given claim or scope, CAR will put up a UI that allows the user to

• –  make a specific choice for the “ask me” claim or scope

• –  see their existing choices -- and change them if desired

• –  save their new choices -- or not (using them just for this particular request)

• CAR’s UI also current offers the user the choice to “show me this screen again.” This choice causes CAR to put up the “ask me” UI even if there are no “ask me” policy choices.

Point Of Admin For Self-Service Option

CAR’s policy retrieval and setting REST API -- along with its UI -- allow a user to create persistent policies about their claims and scopes on a per-RP basis.

• –  CAR needs to be configured with an authentication service to use.

• –  CAR already integratable with Shibboleth IdP V3

Interesting features:

– “All other claims and scopes” required setting ensures that requests with “new” claims/scopes can be addressed

• User choices are permit, deny, “ask me” and “use advice” – “While I’m Away” required setting.

• As discussed, applies for “ask me” decisions if the user is offline or “prompt = none.” – “New RP Template.” CAR creates a new policy from the template when a new RP makes a request.

• Each user has their own “new RP template” and can customize it.

• Allows user to “set it and forget it”

• “Ask me” is the default policy (without any user action) for “all claims and scopes”

Point Of Admin For RS/AS Managers

While OIDC is oriented toward end users, CAR allows for the possibility of the RS/AS’s own policies about users, RPs, and claims and scopes. These

– typically serve as “advice” shown to the user.

– can serve to override user choices in emergencies (or as SOP).

Policy Store Only option

In this case, CAR is simply holding policies for an AS. The policies would conform to CAR’s policy language of course.

• The AS would retrieve a user’s policy for a given RP -- or any subset of policies it wants using CAR’s REST API.

• The AS would then act as to make permit/deny decisions on requested claims and scopes.

• The AS would also serve as the point of administration for policies, putting up its own UI, instead of using’s CAR’s.

Modeling Resources & Scopes For Self-Service

In CAR, to allow for self-service, the resource id needs to be the user’s identifier, not a low level resource (such as a single photo).

Scopes In CAR:

• –  Called Information items, “info items” for short in CAR documentation.

• –  Can be “anything” since CAR doesn’t interpret the info item string.

• CAR needs a display name and description for each info item (see next section!)

– scope itself doesn’t need to be a clickable URL for UI to inform user. – We recommend that each scope represent an “action on category” pair. E.g.

• view_familyPhotos • print_Selfies

The type of scope modeling allows for easier management by a user:

• –  Too many scopes could overwhelm a user (in our opinion).

• –  Exceptions to a category -- e.g. a single photo -- could still be called out.

Informed Content Registration For Scopes

The CAR team is “in-progress” on creating the API that allows for registration of key information about scopes, claims, and attributes.

Note: OAUTH does not define the interface or protocol between the resource server and the AS. Here’s a quote from OAUTH 2.0 Authorization Framework Section 1.1 Roles:

• The interaction between the authorization server and resource server is beyond the scope of this specification. The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.

We expect the RS to register scopes/claims with the AS, which then registers them with CAR.

• –  The “resource id” would be the user’s id.

• –  No need to pre-register users (we have a “new user config” that creates policy on the fly).

Here is an over of the registration info CAR needs.....

Registration Info Overview

• Raw id of the scope/claim/attribute as defined by its Resource Holder’s (RH)

• Display string for item

• Description string for item

• Is the item “sensitive” as per GDPR and other standards?

• Is the item a “negative permission” input?

• –  E.g. “Malevolent User,” “persona non-grata”

• –  CAR “always sends” but “never displays” these items.

• –  Reason: We don’t want the user to “consent away” a negative permission.

There is further registration info, more pertinent to attributes than scopes/claims.