[mitreid-connect] UMA Permission ticket claims

[Justin Richer]

Yes, the UMA spec is completely full of holes and magic at that stage. I don’t have HTTP dumps but our implementation expects the client to send the requesting party, in a web browser, to the claims gathering endpoint. There, the requesting party will be prompted to enter their email address (technically, their webfinger identifier) to start an OpenID Connect login flow. Once that’s completed, the server will redirect back to the client’s claims redirect URI (not the normal redirect URI) with a parameter indicating that some claims have been submitted. At this stage, the client just needs to make the call to the RPT request again.

 — Justin


> On Nov 30, 2015, at 1:14 PM, Luiz Omori <luiz.omori at duke.edu> wrote:
> 
> Thanks.
> 
> Would you have any examples (http dumps, code) of the last step you mentioned below? I think I have everything in place up to the first RPT request failure so now need to process properly the Authorization Server’s Request for Additional Information. I’m checking the spec but there are quite a few MAYs there.
> 
> Regards,
> Luiz
> 
> From: Justin Richer
> Date: Monday, November 30, 2015 at 12:37 PM
> To: Luiz Omori
> Cc: "mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>"
> Subject: Re: [mitreid-connect] UMA Permission ticket claims
> 
> First off, the UMA functionality is considered “beta” at this stage, so it’s functional but don’t be surprised if things do break from time to time. :)
> 
> With that in mind: The way the system works is that you need to set up a resource set, then set a policy on that set. The policy contains a set of claims that are required to be fulfilled before handing a token to the client. Our system will only take claims in the form of OpenID Connect identity claims. In particular, we’ve streamlined the UI to do an email-based check, using webfinger as a bridge between domains and systems. 
> 
> After you have the policy set, you get a permissions ticket. This ticket doesn’t have any claims fulfilled on it yet, so when the client goes to get an RPT with it, it will fail. There are no claims inside the AAT or even associated with the AAT. (In a future version of the spec, the AAT is likely to be dropped entirely.) 
> 
> The RS never provides claims to fulfill a ticket, that’s the job of the client and the RqP. In our implementation, the RqP needs to log in to the claims gathering endpoint with OpenID Connect, which will cause the claims associated with that user’s ID token and user profile to be associated with the ticket. The ticket will then need to be presented by the client to the RPT endpoint again to try to get the RPT. This time, if the claims in the ticket satisfy the claims in the resource set, then the token is granted.
> 
> Without this step, there’s absolutely no way to tell if the authorization server should issue the RPT.
> 
>  — Justin
> 
>> On Nov 30, 2015, at 12:10 PM, Luiz Omori <luiz.omori at duke.edu <mailto:luiz.omori at duke.edu>> wrote:
>> 
>> Hi,
>> 
>> I have been trying to retrieve an UMA RPT token but it’s failing where AuthorizationRequestEndpoint tries to verify that the resource set required claims are provided in the permission ticket. I did create a sharing policy for the resource. Apparently my Permission Ticket is missing “email_verified”, “sub”, “email”. Questions:
>> Why is this verification done at all? Isn’t the Resource Server the one that requests Permission Tickets and provide them to the client? Shouldn’t the Resource Set required claims be verified against the claims within the AAT?
>> What is the correct way to pass claims during the Permission Ticket request? Currently my RS is requesting it by providing a PAT token and filling the body with resource_set_id plus some scopes.
>> ClaimProcessingResult result = claimsProcessingService.claimsAreSatisfied(rs, ticket);
>> 
>> I’m quite new to UMA.
>> 
>> Regards,
>> Luiz
>> _______________________________________________
>> mitreid-connect mailing list
>> mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>
>> http://mailman.mit.edu/mailman/listinfo/mitreid-connect <http://mailman.mit.edu/mailman/listinfo/mitreid-connect>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20151130/2dd06aa9/attachment.html