[keycloak-user] Re-2: Multi attribute authorization check

christian lutz christianlutz at inovel.de
Fri Sep 15 04:44:01 EDT 2017


Hello,

Do you know the keycloak photoz example? https://github.com/keycloak/keycloak/tree/master/examples/authz/photoz

Based on this idea we solved the same problem like this.

- For each company we crate a new resource containing a company id within the type like company:id:11
- Each user will be added to one company role.
- Each company role contains an attribute like companyId=11
- You need to add this attribute to you token (see mapper)
- We created a simple javascript policy 
This policy checks if the requested resource and the logged-in user having the same company id.


Regards
Christian



-------- Original Message --------
Subject: Re: [keycloak-user] Multi attribute authorization check (15. September 2017, 08:46)
From:    Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>
To:      christianlutz at inovel.de

> How about using different clients for different companies? You can control 
> the scopes the clients may ask for.

Best regards,
Sebastian

Mit 
> freundlichen Grüßen / Best regards

Dr.-Ing.  Sebastian Schuster


> Engineering and Support (INST/ESY1) 
Bosch Software Innovations GmbH | 
> Schöneberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
Tel. +
> 49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com


> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 

> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-
> Ing. Rainer Kallenbach, Michael Hahn 




-----Original Message-----
From: 
> keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.
> jboss.org] On Behalf Of Nathan Hoult
Sent: Donnerstag, 14. September 2017 
> 19:51
To: keycloak-user at lists.jboss.org
Subject: [keycloak-user] Multi 
> attribute authorization check

I have a use case where I need to check if a 
> (user)+(company) is authorized for a client resource.

Example:
user + 
> companyA = resourceA granted
user + companyB = resourceA denied

The user 
> may have multiple browser sessions logged into the same client so I can't 
> just set a KC user attribute "company=companyA". The service will know, 
> based on cookie or something, what the company ID is and can pass that 
> information to KC which can then return if that resource is authorized.

I 
> tried:
1) Scope per company: I got close but it seemed to be the wrong use 
> of scope. I ran into some issues but if this was the way to do it I can 
> look at it again.
2) Realm per company: then the user would have multiple 
> accounts, clients would have to trust multiple Realms, added/removing 
> companies would require a Realm setup, and any clients resources changes 
> would require an update in each Realm. There is also the problem of a 
> resource being controlled by multiple authorization servers seems wrong ( 
> https://github.com/pingidentity/mod_auth_openidc/issues/199).

I have 
> thought about a hybrid approach but didn't think it was the right way to do 
> it even if it worked: 1 client realm with all users and clients, that realm 
> trusts multiple per company reals, then a user logs into a company realm 
> that the client converts to the client realm but puts in the token which 
> realm the user came from.

I could write my own service, let the 
> applications deal with their own resource permissions, or make KC plugin 
> that does what I want, but if KC can't do it by default does anyone know of 
> another AuthZ implementation that could?

I could be thinking about the 
> problem all wrong to begin with so any input is appreciated.

Thanks,
- 
> Nathan
_______________________________________________
keycloak-user 
> mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/
> listinfo/keycloak-user

_______________________________________________

> keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.
> jboss.org/mailman/listinfo/keycloak-
> user



More information about the keycloak-user mailing list