Re: [WG-UMA] Keycloak support for UMA 2.0

On Fri, Aug 17, 2018 at 1:34 AM, Eve Maler wrote:

Thanks to both of you and sorry for this belated followup.

It sounds like there may be a few different use cases to think about here. Hoping to tease them out a bit.

First, Pedro, when you talk about security and not privacy, and non-user-managed resources, I wonder: Are these literally enterprise-owned resources vs. "consumer" use cases you're talking about in this specific case, that is, what we've sometimes called "enterprise UMA" (the resource owner is an organization)? The same org could have this use case and also (maybe eventually) human end-user use cases.

Yes. So you are basically enforcing access to resources based on the permissions managed by the resource server itself. Does not necessarily imply end-users managing their own resources. For instance, my API has an endpoint "/api/employee/{id}". There are some permissions, managed by the RS, that defines who/how/when/what can access that endpoint. Things like "only employee and managers can access", etc.

Second, I think I understand what you're doing now in the case of the permission endpoint extension. The RS is collecting claims to satisfy its own need for additional/stricter authorization ("Adrian clause"), and it's providing this additional context to the AS so the latter can display this info to the RO (I guess potentially as part of an access approval flow?). Let me know if I got that wrong.

Yes, where the collected claims could be used by policies to perform contextual-based access control too. What you mentioned about "info to the RO" is something we don't do at the moment, but it is a possibility. So we could show to RO more information about the authorization request he is about to approve. This also can be used to enable claims gathering on RS side.

Third, it sounds like the specific suggestion you made in #355 has turned into an additional "off-label" flow that you support, I guess you could say another extension. I haven't looked this up in your documentation yet, but we had discussed how the RS would act as a direct conduit for security requests and resulting tokens that the client would normally request from the AS. (Justin's recommendation at the time, iirc, was to use one of the more classic OAuth grants vs. the UMA grant, but then maybe you don't get UMA's asynchronicity??) It would be interesting to drill into this more -- at least I for one am interested. :)

I created #355 with the "enterprise UMA" use cases in mind. Based on well known patterns such as PEP and PDP. A PEP in front of the RS just need to enforce access based on decisions from PDP. The key point here is that we are token-based, so PEP can: 1) Enforce access based on permissions within the token in case token has a known format (JWT) / (or by invoking token introspection) 2) Enforce access based on permissions granted by the server after a successful authorization request Regarding #1, clients should be able to obtain tokens with permissions. It does not really matter if you are using UMA flow or something else. In our case, we have an alternative protocol that allow clients to obtain RPTs based on access tokens. We allow clients to obtain permissions based on a set of one or more resources/scopes, or even obtain all permissions from server, we allow clients to limit number of permissions in a response, we allow clients to define the response format (a regular token response, just a decision or a JSON with only the permissions granted by the server), etc. Note that client and RS are colocated, clients may know about the resources protected by the RS. Clients could even perform some logic on their side to hide/show/restrict specific parts of the functionality they provide based on these permissions (for instance, SPAs). Regarding #2, access involves calls to the AS in order to check whether or not access to a resource should be granted (classical PEP <-> PDP). In this case, clients don't know about resources protected by RS. They just try to access some endpoint with the access token they have in hands.

Fourth, Adrian, you bring up the challenges of client app trust, particularly in the context of a loosely coupled AS and RS (which UMA has done a lot of deep work around, but which is starting to creep into the OAuth WG's thinking a bit now too). If there were outputs from the meeting in DC that describe the requirements around warnings, can we take a look? It's a bit odd to say that it's the RS that doesn't trust the client app, given that the RS doesn't really have a relationship with the client; the AS does. (The AS is what issues and checks client credentials.)

Don't know about the requirements, but yeah, we can take a look :) Agree that AS is the main authority. But I think RS can also decide whether or not a client is trustworthy. Even if backed by information from AS. For instance, what if RS only allow access from Client X if authentication level is Y ?

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Aug 9, 2018 at 4:04 PM, Adrian Gropper wrote:

...

inline, from the eponym...

On Thu, Aug 9, 2018 at 3:37 PM, Pedro Igor Silva wrote:

...

Hi Eve,

Thanks for updating that page.

In our last discussion that originated #355, you mentioned the "Adrian Clause". This is exactly what we are trying to achieve with this extension to permission endpoint, even if an RPT provides sufficient permissions for a particular case, the resource server can choose to bar access based on its own criteria. Where the criteria can be based on information from runtime or some external service. I think this also allows the RS to provide some "claims gathering" flow on its side, prior to issuing a permission ticket. It should also allow the AS to present to the resource owner more details on what he is approving.

Fresh from a 3-day meeting hosted by the US health regulators in DC, the issue of how resource servers (hospitals) balance security and privacy of the OAuth API remains contentious and UMA is, sadly, not yet in the conversation. The law and regulatory interpretations are pretty clear that the patient has an absolute right to authorize access by any RqP client (the privacy part) as long as that client does not impact the security of other patients such as through DoS or SQL injection (the security part).

The RSs are allowed to warn the resource owner if they do not trust the "software statement" presented by the RqP's Client but the current OAuth architecture does not consider that the AS operator might be independent of the RS operator. There is also no consensus on what governance mechanisms will apply to the issuers of software statements about the client.

I'm not familiar with Keycloak and have not heard of any uses in healthcare. Our discussion should be clear about whether the claims refer to, and hold accountable, the RqP or their Client. This is a major issue as we try to convince healthcare OAuth RSs to implement dynamic client registration (as a step toward UMA).

In cases where the RS does not trust the Client's software statement, they MAY choose to warn the resource owner. It's not clear what the mechanism for this warning should be whether the RS controls the AS or not, particularly since the resource owner might not be online when the RqP comes a-knocking.

...

As I mentioned before, people are usually interested in security and not privacy, so most of the use cases don't have "user-managed" resources. A vision that I think that will change considering all the concerns around privacy we are facing.

Agreed, if by "people" you mean resource servers rather than the actual people (RqPs and Resource Owners) who, unfortunately, are not the customer for most of the stuff we sell as IT. Hopefully, the rise of GDPR and CA privacy laws will change that.

Adrian

...

The issue #355 is mainly related to finding a UMA compliant solution that could help people looking for security. Cases where you don't necessarily need a permission ticket, but a smart PEP (in front of RS) that is capable of interacting with the AS to obtain permissions/decisions. For instance, our implementation allows using UMA grant type without a ticket to pass the name/ids of resources and scopes you want to check for access. I'm not proud of using UMA grant type for that, maybe best would be a different grant type, but we decided that a single grant type would make things easier for users.

Regards. Pedro Igor

On Thu, Aug 9, 2018 at 2:45 PM, Eve Maler wrote:

...

Hey again Pedro,

Wanted to let you know that the group took a look at the Keycloak news in the call today, and I've updated the Implementations page with the details and links. Congrats!!

We had some questions about the purpose of the permission endpoint and if this is something that makes sense to standardized for any interop purpose, or whether it would be internal to the ecosystem in question:

====

https://kantarainitiative.org/confluence/display/uma/UMA+tel econ+2018-08-09

It appears that there is an extension to the permission endpoint https://www.keycloak.org/docs/latest/authorization_services/index.html#_serv... to all the RS to push claims to that endpoint. "When creating tickets you can also push arbitrary claims and associate these claims with the ticket ... (example shown) ... Where these claims will be available to your policies when evaluating permissions for the resource and scope(s) associated with the permission ticket.". Is is something that would be interesting to standardize for interop? We can ask Pedro in email. He had proposed an extension (see issue 355 https://github.com/KantaraInitiative/wg-uma/issues/355) that would shortcut using a permission ticket at all, for narrow-ecosystem enterprise purposes.

====

What do you think? Thanks,

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Aug 7, 2018 at 11:38 AM, Mike Schwartz wrote:

...

Way to go Pedro!!! Great news!!!

The Gluu Gateway could act as the UMA RS, and we have a demo UMA client too. If you have an Internet accessible instance, we'd be interested to test that with you. Perhaps it could lead to a wider interop with WS02 and ForgeRock too (i.e. keep the RS and client constant).

If you want to chat, email me off list.

- Mike

------------------------ Michael Schwartz Gluu Founder / CEO mike@gluu.org https://www.linkedin.com/in/nynymike/

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/