On Mar 1, 2018, at 10:27 AM, Anil Saldanha <asaldanha1947(a)gmail.com&gt; wrote: Pedro, my personal opinion here. The goal of the Entitlements API is to use for contextual authorization. It does not just rely on user attributes including privacy. There are other aspects to the context - resource attributes, environmental attributes, channel attributes etc. :-) UMA is focused on User managed attributes and privacy controls. While you are trying to unify the api into one under the UMA endpoint umbrella, I feel that it may be better to keep them separate. If the Entitlements API usage by users/applications is very very low, just drop it and start using the new UMA grant type. Regards, Anil > On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > Hi, > > There are situations where you don't want to use the UMA protocol to obtain > permissions from the server in form of an access token. Reasons can be: you > don't have any privacy requirements or your requirements don't require all > the UMA dance to obtain an access token. > > In these situations, you may just want to send a request with the resources > and scopes you want to get access and get back the access token with these > permissions. > > This is what we provide today with the Entitlement API, an alternative that > simplifies how clients can obtain permissions from the server. > > However, with the introduction of UMA 2.0 support, we have now a specific > grant type [1] for obtaining permissions from the server using the token > endpoint. Just like any other OAuth2 grant type, the UMA grant type expects > a HTTP FORM request with some parameters. > > The Entitlement API no longer exists but the same behavior can be achieved > with the new UMA grant type that was introduced. In other words, you can > use this grant type to ask for an access token with permissions without > sending a permission ticket but a list of resources/scopes (as parameters) > you want to get access. > > The reason for reusing the grant type is that I would like to avoid having > two endpoints for obtaining permissions from the server. I think it makes > things simple. > > Would like to know your opinion if moving the Entitlement API functionality > to this new grant type makes sense and if, maybe, we should have a specific > grant type (based on UMA grant type) that allows authorization requests > without a permission ticket (but a list of resources and scopes you want to > access). As side note, the code for UMA and non-UMA authorization is pretty > much the same, the main difference is on the format of the authorization > request/protocol. > > [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

Pedro, my personal opinion here. The goal of the Entitlements API is to use for contextual authorization. It does not just rely on user attributes including privacy. There are other aspects to the context - resource attributes, environmental attributes, channel attributes etc. :-)

UMA is focused on User managed attributes and privacy controls.

While you are trying to unify the api into one under the UMA endpoint umbrella, I feel that it may be better to keep them separate.

If the Entitlements API usage by users/applications is very very low, just drop it and start using the new UMA grant type.

Regards, Anil On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > Hi, > > There are situations where you don't want to use the UMA protocol to > obtain > permissions from the server in form of an access token. Reasons can be: > you > don't have any privacy requirements or your requirements don't require all > the UMA dance to obtain an access token. > > In these situations, you may just want to send a request with the > resources > and scopes you want to get access and get back the access token with these > permissions. > > This is what we provide today with the Entitlement API, an alternative > that > simplifies how clients can obtain permissions from the server. > > However, with the introduction of UMA 2.0 support, we have now a specific > grant type [1] for obtaining permissions from the server using the token > endpoint. Just like any other OAuth2 grant type, the UMA grant type > expects > a HTTP FORM request with some parameters. > > The Entitlement API no longer exists but the same behavior can be achieved > with the new UMA grant type that was introduced. In other words, you can > use this grant type to ask for an access token with permissions without > sending a permission ticket but a list of resources/scopes (as parameters) > you want to get access. > > The reason for reusing the grant type is that I would like to avoid having > two endpoints for obtaining permissions from the server. I think it makes > things simple. > > Would like to know your opinion if moving the Entitlement API > functionality > to this new grant type makes sense and if, maybe, we should have a > specific > grant type (based on UMA grant type) that allows authorization requests > without a permission ticket (but a list of resources and scopes you want > to > access). As side note, the code for UMA and non-UMA authorization is > pretty > much the same, the main difference is on the format of the authorization > request/protocol. > > [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

Authorization is pretty hard for people to wrap their heads around. Now if you try to push the UMA dance (however good it is) as the holy grail for all your authorization needs, it may make things more confusing. That is why people just stick to authentication and passwords because everything else is hard. :) On Thu, Mar 1, 2018 at 11:24 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > Hey Anil ! > > I appreciate the feedback. > > On Thu, Mar 1, 2018 at 1:27 PM, Anil Saldanha <asaldanha1947(a)gmail.com&gt; > wrote: > >> Pedro, >> >> my personal opinion here. >> >> The goal of the Entitlements API is to use for contextual >> authorization. It does not just rely on user attributes including >> privacy. There are other aspects to the context - resource attributes, >> environmental attributes, channel attributes etc. :-) >> > > In addition to that, we try to provide a more lightweight protocol for > obtaining permissions from the server. > > > >> UMA is focused on User managed attributes and privacy controls. >> > > True but with UMA it should also be possible to push contextual data, > considering that the resource server is responsible to create permission > tickets and put whatever data they want there. So we can use these same > data later when evaluating policies. In Keycloak permission tickets are > not persisted and are short-lived. Of course, depending on the "contextual" > data you have in a permission ticket more quickly you need use it. > Otherwise you may evaluate policies with stale data. > > >> >> While you are trying to unify the api into one under the UMA endpoint >> umbrella, I feel that it may be better to keep them separate. >> > > I'm not really trying to "unify" both approaches, you know. But have the > Entitlement API also working using the standard OAuth2 Token Endpoint, > which a specific grant type. Like I said, right now I'm reusing > "urn:ietf:params:oauth:grant-type:uma-ticket" but I'm inclined to define > a specific grant type for the "entitlement api", something like > "urn:ietf:params:oauth:grant-type:kc-entitlement". > > In a nutshell, the "unification" here is basically an alignment with > OAuth2 standard. An extension/custom grant type. > > >> >> If the Entitlements API usage by users/applications is very very low, >> just drop it and start using the new UMA grant type. >> > > My feeling is that Entitlement API usage is higher than UMA. I think the > main reason for that is that people is not yet (but I believe more and more > privacy will be a first-class concern to apps and services) concerned about > privacy. But security ... and how to protect APIs and application resources. > > I have seen people get really confused about the UMA dance ... But that > is until they understand all motivations and the beauty behind it :) > > >> >> Regards, >> Anil >> >> On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >>> Hi, >>> >>> There are situations where you don't want to use the UMA protocol to >>> obtain >>> permissions from the server in form of an access token. Reasons can be: >>> you >>> don't have any privacy requirements or your requirements don't require >>> all >>> the UMA dance to obtain an access token. >>> >>> In these situations, you may just want to send a request with the >>> resources >>> and scopes you want to get access and get back the access token with >>> these >>> permissions. >>> >>> This is what we provide today with the Entitlement API, an alternative >>> that >>> simplifies how clients can obtain permissions from the server. >>> >>> However, with the introduction of UMA 2.0 support, we have now a >>> specific >>> grant type [1] for obtaining permissions from the server using the token >>> endpoint. Just like any other OAuth2 grant type, the UMA grant type >>> expects >>> a HTTP FORM request with some parameters. >>> >>> The Entitlement API no longer exists but the same behavior can be >>> achieved >>> with the new UMA grant type that was introduced. In other words, you can >>> use this grant type to ask for an access token with permissions without >>> sending a permission ticket but a list of resources/scopes (as >>> parameters) >>> you want to get access. >>> >>> The reason for reusing the grant type is that I would like to avoid >>> having >>> two endpoints for obtaining permissions from the server. I think it >>> makes >>> things simple. >>> >>> Would like to know your opinion if moving the Entitlement API >>> functionality >>> to this new grant type makes sense and if, maybe, we should have a >>> specific >>> grant type (based on UMA grant type) that allows authorization requests >>> without a permission ticket (but a list of resources and scopes you >>> want to >>> access). As side note, the code for UMA and non-UMA authorization is >>> pretty >>> much the same, the main difference is on the format of the authorization >>> request/protocol. >>> >>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2. >>> 0-09.html >>> >>> Regards. >>> Pedro Igor >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >