[keycloak-user] Obtaining permissions for resources which are not registered as Keycloak Resources

Pedro Igor Silva psilva at redhat.com
Mon Mar 12 07:43:41 EDT 2018


Hi Marcel,

These are all valid concerns.

Currently, we are working with some improvements to policy enforcers and
evaluation API. Some of them can help you achieve what you want:

* https://issues.jboss.org/browse/KEYCLOAK-6794
* https://issues.jboss.org/browse/KEYCLOAK-6628
* https://issues.jboss.org/browse/KEYCLOAK-6529

I do think your problem is pretty much related with KEYCLOAK-6529 as we are
planning to include some common information in a permission ticket such as:

* HTTP request information such as path, path parameters, request
parameters, etc.
* Provide some way that you, as a developer, can push any other claim to a
permission ticket

I have one question though. Have you implemented a custom Policy Provider
using the Policy Provider SPI ? Or are you just using a Javascript policy ?

Regards.
Pedro Igor

On Mon, Mar 12, 2018 at 6:41 AM, Marcel Német <marcel.nemet at gmail.com>
wrote:

> Hi,
>
> We have an application with a large number of documents which are being
> sent between companies. A company can have multiple users. We have many
> companies and users can (on behalf of their company) send documents to
> other company. Then the document can be accessed either by the users of the
> sending company or the users of the receiving company. All documents can be
> also accessed by our customer-care operators (but this is a simple case
> which can be easily covered by the role-based access control). Our data and
> users are in SQL Server DB, so we would like to use user federation
> interfaces to get the users.
>
> I would like to solve the problem in following way:
> 1. Using the user federation "company ID" custom attribute to the identity
> token of each user.
> 2. Write a rule-based Policy in Java or JavaScript named "Only users which
> belong to a sender or receiver company"
> 3. When somebody wants to access a document with ID "abc-123" which was
> sent by company "bbb" and received by company "ccc" the Java or JavaScript
> policy could - based on the resource ID "abc-123" and based on the "company
> ID" custom attribute - query our database to see whether the "company ID"
> of the logged-in user is a sender company or a receiver company of a given
> document
> 3*. Optionally the sender and receiver company of the document could be
> sent along as additional attributes in the permission ticket by the policy
> enforcer, then the resource server would do the reading from the database
> and Keycloak Policy can decide without DB connection. But I am not sure
> this is secure, the permission ticket from policy enforcer could be
> manipulated and the company ID of a hacker's company could be added as a
> sending company, then the hacker could access all documents. But I guess
> permissions tickets are protected against manipulation.
>
> The problems which I am facing:
> Regarding the step 3., the only way to get "document ID" to the
> $evaluation.permission variable of the Java/JavaScript Policy is to create
> a Keycloak resource for every single document with a matching name and a
> matching URI (e.g. name= "abc-123"  and URI= "/document/ abc-123").
>
> It seems complicated for me to create a resource for every document which
> we have and then delete those resources when we delete the documents since
> the same policy applies to all documents anyway. We have huge numbers of
> documents being sent every day between companies. At the same time, if we
> do not create a Keycloak resource for every document, then I believe we can
> not configure the policy enforcer to use the "/document/{id}" wildcard. The
> Authorisation server will not receive the document ID unless there is a
> Keycloak resource with the same name. Ideally, the Keycloak server should
> be able to grant permissions even if it does not have a resource registered
> and apply policies registered with URI /document/*. The
> $evaluation.permission variable should hold the also the full URI not the
> one with a wildcard. I understand that currently, the URI in
> $evaluation.permission will be "document/*" even when a user is accessing
> "/document/abc-123" (unless we create a Keycloak resource for every
> document with a matching URI).
>
> To summarize:
> It would be great if the policy enforcer could obtain permissions to access
> document  "abc-123" even without creating resource "abc-123" in Keycloak.
> The idea is that the policy enforcer asks "Can this user access
> document abc-123?"
> and the Java policy in the Keycloak can decide based on the ID of the
> resource and additional data inside the identity token or based on queries
> to our DB.
> Is there a workaround or recommended solution?
>
> I have read through the previous mail-list topics below, and I saw that
> some user "hacked" the policy enforcer to send the precise URI from the
> policy enforcer. Or is there another way to pass the document ID to
> Keycloak Policy (i.e. inside $evaluation.permission) without creating a
> Keycloak resource for every document? Is there a feature request in Jira
> which would cover such use cases? Allowing Keycloak to grant permissions
> for resources without having to register all resources in Keycloak would
> make it a more general solution.
>
> Related topics from the mailing list:
>
> "Performance with a large number of resources":
> http://lists.jboss.org/pipermail/keycloak-user/2017-May/010583.html
>
> and
>
> "Additional attributes for an authorization request":
> http://keycloak-user.88327.x6.nabble.com/keycloak-user-
> Additional-attributes-for-an-authorization-request-td2571.html
>
> Kind regards,
> Marcel
> _______________________________________________
> 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