Few clarifications for UMA implementation
Hi All, I am in the middle of implementing the UMA 1.0 core specification for WSO2 Identity Server. I would be grateful if someone could clarify the below points. 1. How do we relate the user consent types with each protected resource when validating in Authorization API? By user consent type what i mean is how the user would give his consent for access( policy, SMS, email etc.). Do we need to sort of maintain a mapping somewhere during implementation? 2. The spec says the on the wire RPT is an opaque string which resolves to an extended JWT. During implementation I am confused whether to maintain a mapping between a unique string to a JWT containing RPT details or to encrypt the RPT(extended JWT) and send it to the client as the RPT string. What would a good approach? -- *A.Farasath Ahamed* Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866 Blog: http://thepseudocode.blogspot.com E-Mail: mefarazath@gmail.com
Hi Farazath,
On 30 Jun 2015, at 12:20 PM, Farazath Ahamed <mefarazath@gmail.com> wrote:
Hi All,
I am in the middle of implementing the UMA 1.0 core specification for WSO2 Identity Server. I would be grateful if someone could clarify the below points.
How do we relate the user consent types with each protected resource when validating in Authorization API? By user consent type what i mean is how the user would give his consent for access( policy, SMS, email etc.). Do we need to sort of maintain a mapping somewhere during implementation? In short, this is not something that is really exposed in UMA proper.
Here’s the long form... Keep in mind that "the user” may be two separate people/parties. There’s the resource owner (who controls the protected resource at the resource server), and the requesting party (who is using the client application that is trying to access the protected resource). The RO might not be around when the RqP is attempting access, unless they happen to be the same person. The AS response to a request for authorization data is explained in Core Sec 3.4 <https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.3.4.1>. Typically, we assume that the AS has the RO’s wishes “on file” in the form of an authorization policy (whose format is out of band of the UMA protocol); success in matching the policy gets the client the authz data they wanted. The RO might of instructed the AS application to ask them in some synchronous way (perhaps by SMS) what to do, in which the AS could tell the client “request_submitted” as an interim step, but the type of action taken on the RO side is not officially exposed to the client/RqP side. If the client fails to match the policy, the AS might return “need_info” or “not_authorized”. If the AS has no RO policy on file, the AS application could choose to notify the RO through email (or however) about pending requests for the RO to consider later, in case they want to make new policies at that time. Obviously, some of what I’ve described here is protocol behavior, and some is “color commentary” on what an application that implements the protocol could choose to do as a form of value-add.
The spec says the on the wire RPT is an opaque string which resolves to an extended JWT. During implementation I am confused whether to maintain a mapping between a unique string to a JWT containing RPT details or to encrypt the RPT(extended JWT) and send it to the client as the RPT string. What would a good approach?
I will let others comment on best practices, efficiencies, and tradeoffs here.
-- A.Farasath Ahamed Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866 Blog: http://thepseudocode.blogspot.com <http://thepseudocode.blogspot.com/> E-Mail: mefarazath@gmail.com <mailto:mefarazath@gmail.com> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
Thanks Eve for the explanation I would be glad if there second point is also clarified. Will wait for the others to comment :) On Wed, Jul 1, 2015 at 1:25 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Hi Farazath,
On 30 Jun 2015, at 12:20 PM, Farazath Ahamed <mefarazath@gmail.com> wrote:
Hi All,
I am in the middle of implementing the UMA 1.0 core specification for WSO2 Identity Server. I would be grateful if someone could clarify the below points.
1. How do we relate the user consent types with each protected resource when validating in Authorization API? By user consent type what i mean is how the user would give his consent for access( policy, SMS, email etc.). Do we need to sort of maintain a mapping somewhere during implementation?
In short, this is not something that is really exposed in UMA proper.
Here’s the long form...
Keep in mind that "the user” may be two separate people/parties. There’s the resource owner (who controls the protected resource at the resource server), and the requesting party (who is using the client application that is trying to access the protected resource). The RO might not be around when the RqP is attempting access, unless they happen to be the same person.
The AS response to a request for authorization data is explained in Core Sec 3.4 <https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.3.4.1>. Typically, we assume that the AS has the RO’s wishes “on file” in the form of an authorization policy (whose format is out of band of the UMA protocol); success in matching the policy gets the client the authz data they wanted. The RO might of instructed the AS application to ask them in some synchronous way (perhaps by SMS) what to do, in which the AS could tell the client “request_submitted” as an interim step, but the type of action taken on the RO side is not officially exposed to the client/RqP side.
If the client fails to match the policy, the AS might return “need_info” or “not_authorized”. If the AS has no RO policy on file, the AS application could choose to notify the RO through email (or however) about pending requests for the RO to consider later, in case they want to make new policies at that time.
Obviously, some of what I’ve described here is protocol behavior, and some is “color commentary” on what an application that implements the protocol could choose to do as a form of value-add.
1. The spec says the on the wire RPT is an opaque string which resolves to an extended JWT. During implementation I am confused whether to maintain a mapping between a unique string to a JWT containing RPT details or to encrypt the RPT(extended JWT) and send it to the client as the RPT string. What would a good approach?
I will let others comment on best practices, efficiencies, and tradeoffs here.
-- *A.Farasath Ahamed* Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866 Blog: http://thepseudocode.blogspot.com E-Mail: mefarazath@gmail.com _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
-- *A.Farasath Ahamed* Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866 Blog: http://thepseudocode.blogspot.com E-Mail: mefarazath@gmail.com
participants (2)
-
Eve Maler -
Farazath Ahamed