inline, from the eponym...

On Thu, Aug 9, 2018 at 3:37 PM, Pedro Igor Silva <psilva@redhat.com> wrote:
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.

Fresh from a 3-day meeting hosted by the US health regulators in DC, the issue of how resource servers (hospitals) balance security and privacy of the OAuth API remains contentious and UMA is, sadly, not yet in the conversation. The law and regulatory interpretations are pretty clear that the patient has an absolute right to authorize access by any RqP client (the privacy part) as long as that client does not impact the security of other patients such as through DoS or SQL injection (the security part).

The RSs are allowed to warn the resource owner if they do not trust the "software statement" presented by the RqP's Client but the current OAuth architecture does not consider that the AS operator might be independent of the RS operator. There is also no consensus on what governance mechanisms will apply to the issuers of software statements about the client.

I'm not familiar with Keycloak and have not heard of any uses in healthcare. Our discussion should be clear about whether the claims refer to, and hold accountable, the RqP or their Client. This is a major issue as we try to convince healthcare OAuth RSs to implement dynamic client registration (as a step toward UMA).

In cases where the RS does not trust the Client's software statement, they MAY choose to warn the resource owner. It's not clear what the mechanism for this warning should be whether the RS controls the AS or not, particularly since the resource owner might not be online when the RqP comes a-knocking.

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.

Agreed, if by "people" you mean resource servers rather than the actual people (RqPs and Resource Owners) who, unfortunately, are not the customer for most of the stuff we sell as IT. Hopefully, the rise of GDPR and CA privacy laws will change that.

Adrian

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 <eve@xmlgrrl.com> wrote:
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:

====


It appears that there is an extension to the permission endpoint 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) 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 <mike@gluu.org> 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



_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma




--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.