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
On Thu, Aug 9, 2018 at 2:45 PM, 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+tel econ+2018-08-09
It appears that there is an extension to the permission endpoint https://www.keycloak.org/docs/latest/authorization_services/index.html#_serv... 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 https://github.com/KantaraInitiative/wg-uma/issues/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
On Tue, Aug 7, 2018 at 11:38 AM, Mike Schwartz
wrote: 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 mike@gluu.org https://www.linkedin.com/in/nynymike/
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma