[WG-UMA] Keycloak support for UMA 2.0

[Pedro Igor Silva]

Hi All,

Keycloak [1] project is now supporting UMA 2.0. Except for claims gathering flow, most of the specification is implemented.

The main features we support are:

* Resource registration

In a nutshell, the only thing we don't have yet from UMA specs is claims gathering flow. Documentation is here [1]. A simple example app (photoz) using UMA can be checked here [2].

We have extended the Protection API to include a new endpoint to manage user permissions [3]. It was a result of contributions from the community in order allow RSs to associate/manage custom policies for resources while still letting users manage them.

While we don't have support for claims gathering, RSs are allowed to push claims when creating a permission ticket [4].

Will summarize those points and prepare the e-mail.

Thanks.
Pedro Igor

[1] https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_user_managed_access

[2] https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-uma-photoz

[3] https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_authorization_uma_policy_api

[4] https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_protection_permission_api_papi

[Pedro Igor Silva]

Sorry, sent the e-mail before completing it :). Please, ignore the first one.

Hi All,

Keycloak [1] project is now supporting UMA 2.0. Except for claims gathering flow, most of the specification is implemented. Documentation is available here [2].

The main features we support are:

* Resource registration

* Permission Ticket management

In a nutshell, the only thing we don't have yet from UMA specs is claims gathering flow. Documentation is here [1]. A simple example app (photoz) using UMA can be checked here [2].

We have extended the Protection API to include a new endpoint to manage user permissions [3]. It was a result of contributions from the community in order allow RSs to associate/manage custom policies for resources while still letting users manage them.

While we don't have support for claims gathering, RSs are allowed to push claims when creating a permission ticket [4].

Will summarize those points and prepare the e-mail.

[1] https://www.keycloak.org

[2] https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_user_managed_access

Thanks.
Pedro Igor

[Pedro Igor Silva]

Hi All,

Keycloak [1] project is now supporting UMA 2.0. Except for claims gathering flow, most of the specification is implemented. Documentation is available here [2].

We would appreciate any feedback in order to improve our UMA 2.0 support.

The main features we support are:

* Resource and Permission management through Protection API

* Policy enforcers (for different web containers) supporting UMA 2.0 flow

* Changes to Keycloak Account Service to allow resource owners to manage permissions for their resources

If you want to try it out, we have an example application (photoz) [3] that is available in our repository.

Thanks and sorry for sending all these e-mails :)

Regards.

Pedro Igor

[1] https://www.keycloak.org

[2] https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_user_managed_access

[3] https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-uma-photoz

Thanks.

[Eve Maler]

Thanks, Pedro!

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

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

[Mike Schwartz]

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
mi...@gluu.org
https://www.linkedin.com/in/nynymike/

[Eve Maler]

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+telecon+2018-08-09

It appears that there is an extension to the permission endpoint 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) 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

[Pedro Igor Silva]

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.

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.

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

[Adrian Gropper]

inline, from the eponym...

On Thu, Aug 9, 2018 at 3:37 PM, Pedro Igor Silva <psi...@redhat.com> 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

--

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/

[Eve Maler]

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.

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.

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. :)

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.)

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

[Pedro Igor Silva]

On Fri, Aug 17, 2018 at 1:34 AM, Eve Maler <e...@xmlgrrl.com> 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 ?

[Adrian Gropper]

On Fri, Aug 17, 2018 at 8:46 AM, Pedro Igor Silva <psi...@redhat.com> wrote:

On Fri, Aug 17, 2018 at 1:34 AM, Eve Maler <e...@xmlgrrl.com> wrote:

<SNIP>

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 ?

I see this as out-of-scope for UMA. UMA is a delegation protocol. The RS is free to implement any set of protocols including authentication of the requesting party but I cant't see how UMA can possibly cover the range of business and jurisdictional mandates that could impact an RS decision to override an authorization. That is a very deep ocean. I'm not sure UMA even covers the protocol for the RS to notify the AS that it has been overruled regardless of why.

Adrian

[Cigdem Sengul]

Apologies for jumping into discussion late, but one thing puzzled me below.

 

“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.”

 

Do you rather mean, prior to sending a permission request to AS (and obtaining a permission ticket from it), the RS does some claim gathering? Does the RS do additional access control before registering permission with the client? Are permission requests generated regardless of the state of the claims?

 

Thanks,

--Cigdem

 

Cigdem Sengul, PhD

Senior Researcher 

Website | Twitter | Facebook

 

DD: +44 (0)1865 332256    E: cigdem...@nominet.uk

 

Minerva House, Edmund Halley Road, Oxford Science Park, Oxford, OX4 4DQ, United Kingdom

 

 

Nominet UK. Registered in England and Wales No. 3203859

This message is intended exclusively for the individual(s) to whom it is addressed and may contain information that is privileged, or confidential. If you are not the addressee, you must not read, use or disclose the contents of this e-mail. If you receive this e-mail in error, please advise us immediately and delete the e-mail. Nominet UK has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. However, Nominet cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment.

[Pedro Igor Silva]

On Tue, Aug 21, 2018 at 8:11 AM, Cigdem Sengul <Cigdem...@nominet.uk> wrote:

Apologies for jumping into discussion late, but one thing puzzled me below.

 

“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.”

 

Do you rather mean, prior to sending a permission request to AS (and obtaining a permission ticket from it), the RS does some claim gathering? Does the RS do additional access control before registering permission with the client? Are permission requests generated regardless of the state of the claims?

Yes, that is what I meant. One of the use cases we have is that RS may fetch claims from external services, current HTTP request, etc, in order to push them along with a permission request. You are not forced to do this though.

[Pedro Igor Silva]

I agree, Adrian. I'm mainly considering "enterprise UMA" use cases.

 

Adrian

[Adrian Gropper]

At some point, the enterprise perspective changes to what has been called “cascading authorization servers” because both the RS and the RO each have separate AS.

Adrian