UMA Dev telecon 2015-10-13

Owned by Eve Maler
Last updated: Oct 13, 2015
4 min read

UMA Dev telecon 2015-10-13

Date and Time

Agenda

  • Meetings:
    • We have one more of these scheduled for next week; there's no summertime weirdness
    • Let's get stuff done at IIW!
  • AI review
  • Walk through Roland's code and learn about its design center
  • Review Allan's generic API revisions if any
  • Timeline for rest of 2015
  • AOB

Minutes

Who will be at IIW? Eve, Roland, Rebecka.

Roland's Python implementation is starting off with the RO and a set of resources that they want to share. This is different from the design Allan initially shared.

There's a class that inherits the OAuth dance. There's a bridge between the data source and the authorization server. A library hides the data source details – e.g., is it LDAP, an SQL server, or what? It looks the same regardless. The data class gets a filter that contains information about which part of the database needs to be exported. It turns that into resource set descriptions and passes this over to the class so that registration can be done.

The class called "resource server" is the one with the data source connection. (The purple part of Eve's new diagram.) It achieves:

  • OAuth connection to AS
  • Registration of resource sets (RSR is "config time" – before there's an UMA client in the picture; this is connected most closely to the "purple" part of the diagram)
  • Handling incoming requests ("run time" – or UMA client access attempt time; this is the other two endpoints, and they connect the purple and green parts of the diagram)

So everyone knows that we want to allow the RS to register an array of requested permissions, but that would require an extension to that request format. So if we enable this through our "developer resources", we'd just have to be clear that it's an extension.

Katie has been working on an angular.js implementation. The next conundrum is: How does the RS get client credentials? The UMA spec says that dynamic client registration is perfectly okay. Roland makes this pluggable, using either OAuth's or OpenID Connect's method.

A discussion that is going to come up at IIW is around OpenID Connect federations (or equivalent), that is, where the client credentials are halfway between static and dynamic. The credentials need to be issued mechanically, but with controls imposed in the issuance. Our equivalent would be "access federations" (UMA federations), where both RS's and clients in their relationship with the AS would have mediated/brokered way of getting and maintained credentials. This is where the software statement comes in. This is also where the CommonAccord work of the UMA legal subgroup may be relevant because it could tie in "legal code" to software statements at the OAuth level, and build up to the UMA level. Maybe our outputs could reference the CommonAccord stuff when it's ready (whenever that is).

The type of database or protected resource that you have determines wholly what kinds of requested permissions you could register. A filter picks out what to export, so that you end up protecting vs. allowing some extent of access. The model of protected resource is not completely generic to start with; the use case is LDAP-flavored, and assumes "read-only attribute release". In a way, this could be used for "UMA-protected OIDC"! This isn't the only use case by for, but it's useful to start with something concrete.

The Internet2 folks are currently discussing concretely that UMA matches their "consent management" plans. Thinking about consent management, what about consent receipts? Can we prepare our client libraries for generating audit logs in a flexible fashion? Yes.

Regarding the "identity of an entity" (thinking about LDAP attributes), the user controls some of this, but an administrator controls other elements of it. The subject of an LDAP record may not be the "user" that "manages" the authorized "access" to all of the fields of that record. Alice will tend to be able to manage access to her personal information, such as her email address, but an admin will manage the groups to which she belongs, her role, etc. Alice is not the RO of every field in "her" record. The organization that holds her account may, by contrast, be the RO of those other fields in "her" record. It's not hard to solve in the implementation, but it's important to recognize. There are two different interfaces for Alice (UX) vs. her sys admin (probably REST endpoints).

This gets into a couple of different interesting questions:

  • A split in ROs for different "tightly coupled" resources at the same RS
    • They're different fields in the same record
      • So you just need to be sure you can register the resources appropriately – that is, under the right PAT for each
  • Different design patterns for how to handle "NPE (non-person entity) ROs"
    • When the organization is an RO, what are the ways to interact with the RS to manage resources? Two obvious patterns:
      • Automated: something like a "web service client" acting entirely in an automatic fashion (maybe through REST endpoints or whatever)
      • Manual: a sys admin is an agent of the NPE and logs in to some client, maybe browser-based or native or whatever, on the organization's behalf

When does the class get the PAT and how does it store it? This is down to initialization. When the RO wants to start managing resources, it lets the RS know about the AS, and the OAuth dance unrolls. The PAT gets stored in the class instance. There is a 1:1 match between the PAT and the class instance. PATs need to be quite long-lived, so the storage will need to take this into consideration – does it go into a database, or what? When you instantiate the resource server class, several things happen. When various pieces of information are dynamically gotten, they need to be stored somewhere persistently regardless.

It's early days for the implementation, but Roland intends to give it a handle for where to store the initialization. Jamie suggests a token storage interface. Flexibility could be good here. Same for throwing events into the log for using as receipts etc.

Katie and Jamie might share stuff back and forth offline before next week. She is looking into programming IoT devices.

Attendees

  • Eve
  • Rebecka
  • Jamie
  • Roland
  • Katie
  • Colin
  • Maciej

Â