[keycloak-user] How to implement this using Keycloak

Mon Aug 1 12:38:57 EDT 2016

I will research the KeycloakSecurityContext class then. I can see that including the “unit” id in the path is another way to go.

Yes, I’m using a role-based policy, but instead of applying to individual patients, I apply the policy to a resource represents all patients. In essence, any user with any “unit” role can access the resource, but the filter mechanism described earlier returns the right set of patients for the user. Any better ideas?

Regards.

From: Pedro Igor Silva <psilva at redhat.com>
Date: Monday, August 1, 2016 at 12:26 PM
To: rongsang <rsang at carelogistics.com>
Cc: Travis De Silva <traviskds at gmail.com>, "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] How to implement this using Keycloak

In this case, I think you can just obtain the KeycloakSecurityContext, get the roles from there and then filter patients. Don't think you need a request header for that.

The KeycloakSecurityContext is attached to the request as an attribute. So you just need to obtain it as follows:

KeycloakSecurityContext keycloakSecurityContext = (KeycloakSecurityContext) request.getAttribute(KeycloakSecurityContext.class.getName());

Also, maybe you could do the filtering by having the "unit" id in your path. In this case, the client would just invoke your API passing the "unit" id and get the patients.

So, are you already using our authorization services to enforce policies to individual patients ?

Regards.

----- Original Message -----
From: "Rong Sang (CL-ATL)" <rsang at carelogistics.com>
To: "Pedro Igor Silva" <psilva at redhat.com>, "Travis De Silva" <traviskds at gmail.com>
Cc: keycloak-user at lists.jboss.org
Sent: Monday, August 1, 2016 12:12:16 PM
Subject: Re: [keycloak-user] How to implement this using Keycloak

Hi Pedro,

Thank you for your quick response! Travis… thank you for chiming in too. I agree your use case is the same as mine. Let me first answer Pedro’s questions, and then I explain my use cases in detail.

* Are you the service owner ? Answer: yes, we have the full control of the API.
* Is your service using a REST-style ? How the API looks like ? Answer: it is a REST-style service.
* Is your service already protected using a bearer token ? Answer: yes, more details below.
* How are you representing the user's unit ? Realm, Group, role or just a user claim/attribute ? Answer: Group and role, more details below.
* What is behind: "Users should not have the access to patients in a unit that they are not authorized". What "not authorized" really means ? What kinds of policies you want to apply ? I explain this in the following description of my use case.

In my application, I have patients who stay in the hospital for overnight treatments. They stay in various units based on their diagnosis and treatment plans. In each unit, there are nurses, who are the users of my application. To protect patients’ privacy, a nurse can only view the information of patients who stay in her unit. If a patient is not in the unit that the nurse works in, the nurse should be denied the access to the patient’s information.

Nurse information is stored in a LDAP server. I use Keycloak LDAP module to sync users/groups, and do group-to-role mappings in Keycloak too. Doing so, I will know which nurse works in which units.

I use OAuth tokens for authentication in Keycloak. I use the UMA features for fine-grained authorization. The patient service in my application returns the patient records. Because the service is a REST service, I use a bearer token to protect it. Because I want the service to “filter” the returned patient records based on user’s units (or roles that represent units), I will need to get the units or roles somehow. I think the roles can be a part of the bearer token passed to the server

Here is the api for now. The endpoint is “/patients”, the user/roles information is embedded in the bearer token. I think I can extract roles from the token and map the request to an API call getPatients(units). Here the “units” is equivalent to “roles”.

I think it will be easier if the Keycloak adapter can extract roles and set them in a new request header for me. When the request is mapped to the API call, mapping the roles (filters) is just like mapping a regular request header.

Do you think this is a far-fetched idea? Or do you have better ideas to archive the similar effect?

Thanks!

Rong

From: Pedro Igor Silva <psilva at redhat.com>
Date: Friday, July 29, 2016 at 7:50 PM
To: rongsang <rsang at carelogistics.com>
Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] How to implement this using Keycloak

Hi Rong,

Can you provide more details about your use case ? For instance:

* Are you the service owner ?
* Is your service using a REST-style ? How the API looks like ?
* Is your service already protected using a bearer token ?
* How are you representing the user's unit ? Realm, Group, role or just a user claim/attribute ?
* What is behind: "Users should not have the access to patients in a unit that they are not authorized". What "not authorized" really means ? What kinds of policies you want to apply ?

From what you described, it seems that you can achieve what you want with different approaches. It all depends on what you really need and how fine-grained you want to be. For instance, units can be represented as groups in Keycloak. You can enforce group membership in your application by introspecting the bearer token (issued by a Keycloak server to some client). The same logic applies if you are using roles or attributes to represent units.

In 2.0.0.Final, we have introduced Keycloak Authorization Services. This one is related with externalized and fine-grained authorization, which gives you great flexibility to define, manage, deploy and enforce authorization polices to your application and organization. Indeed, one of the protocols we are supporting (not fully, yet), UMA, is pretty much based on several healthcare use cases. For instance, you can manage the policies that apply to patient records in Keycloak and also let Keycloak enforce these policies to requests sent to your application. In this case, you can define not only a "from unit have access" policy, but also apply even more fine-grained policies to your service using the different policy providers (ABAC and Context-based, RBAC, Time-based, Rules-based, User-based, more to come...) we provide. We are still missing some very nice parts of UMA though, as currently we are focusing on API security use cases. But I hope to get those missing parts implemented soon.

Regards.
Pedro Igor

----- Original Message -----
From: "Rong Sang (CL-ATL)" <rsang at carelogistics.com>
To: keycloak-user at lists.jboss.org
Sent: Friday, July 29, 2016 5:23:20 PM
Subject: [keycloak-user] How to implement this using Keycloak

Hi all,

I’m doing a POC using Keycloak. The normal authentication/authorization features work well, but I have the following requirement that cannot find a straightforward solution for. I hope some security experts in the mailing list can point me to the right direction.

Here is the requirement. A hospital has multiple units. Users should not have the access to patients in a unit that they are not authorized. I have one service that returns a list of patients across units. What’s the best way to set up authorization for this service?

As I said earlier, I cannot find a feature for me to implement this. Any idea is greatly appreciated.

Thanks,

Rong

_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user<https://lists.jboss.org/mailman/listinfo/keycloak-user><https://lists.jboss.org/mailman/listinfo/keycloak-user<https://lists.jboss.org/mailman/listinfo/keycloak-user>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160801/8e8c9f11/attachment-0001.html 