OASIS eXtensible Access Control Markup Language (XACML) TC

Is there any way an OAuth Access Token or Identity Token can be passed in a XACML Request, and have its contents used in a Policy? (I think the answer is no, but checking just in case) Thanks, Rich

Although I am not aware of an implementation that supports this, this seems to be a PEP-specific issue. If the PEP can consume an OAuth/OpenID Connect token (which might require doing OAuth Introspection as well) and turn the content into attributes in an XACML request, the rest of the flow should be orthogonal to where these attributes originate from. Regards, Mohammad ïOn 2018-11-05, 10:24 AM, "xacml@lists.oasis-open.org on behalf of rich levinson" <xacml@lists.oasis-open.org on behalf of rich.levinson@oracle.com> wrote: Is there any way an OAuth Access Token or Identity Token can be passed in a XACML Request, and have its contents used in a Policy? (I think the answer is no, but checking just in case) Thanks, Rich --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi Mohammad, Thanks for the reply. I was thinking that was probably the answer, but wanted to get confirmation. I agree, the PEP probably knows what to do w the token, and if it wants to send info from the token to the PDP, then it needs a vocabulary of AttributeId's in order for a Policy to recognize and process the attribute. Thanks, Rich On 11/5/2018 1:33 PM, Mohammad Jafari wrote: Although I am not aware of an implementation that supports this, this seems to be a PEP-specific issue. If the PEP can consume an OAuth/OpenID Connect token (which might require doing OAuth Introspection as well) and turn the content into attributes in an XACML request, the rest of the flow should be orthogonal to where these attributes originate from. Regards, Mohammad ïOn 2018-11-05, 10:24 AM, "xacml@lists.oasis-open.org on behalf of rich levinson" <xacml@lists.oasis-open.org on behalf of rich.levinson@oracle.com> wrote: Is there any way an OAuth Access Token or Identity Token can be passed in a XACML Request, and have its contents used in a Policy? (I think the answer is no, but checking just in case) Thanks, Rich --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_apps_org_workgroup_portal_my-5Fworkgroups.php&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=nz3Fn66qLx7H4seKWaCIewHybrgY6NYX3PaDZH5uMso&m=2r2E7WDAx-CFmJzNS24SxKemUok_Gm2SxuJ9z8PsU9c&s=NjerES62lCRncIbHwzGUWiBFLm8EzhFh2NKIcn5rt9w&e=

Hi, The token could be parsed by the PEP as suggested in the thread or passed verbatim to the PDP where a PIP could decode it and extract whatever attributes the policy may need. That's what Axiomatics Policy Server does. Note that it's not a PDP's responsibility to validate any token. In federated scenarios, it's quite common to have the PEP pass identity tokens to the PDP. We have customers who do that (SAML and OAuth). David. On Mon, Nov 5, 2018, 9:11 AM rich levinson < rich.levinson@oracle.com wrote: Hi Mohammad, Thanks for the reply. I was thinking that was probably the answer, but wanted to get confirmation. I agree, the PEP probably knows what to do w the token, and if it wants to send info from the token to the PDP, then it needs a vocabulary of AttributeId's in order for a Policy to recognize and process the attribute. Thanks, Rich On 11/5/2018 1:33 PM, Mohammad Jafari wrote: > Although I am not aware of an implementation that supports this, this seems to be a PEP-specific issue. If the PEP can consume an OAuth/OpenID Connect token (which might require doing OAuth Introspection as well) and turn the content into attributes in an XACML request, the rest of the flow should be orthogonal to where these attributes originate from. > > Regards, > Mohammad > > ïOn 2018-11-05, 10:24 AM, " xacml@lists.oasis-open.org on behalf of rich levinson" < xacml@lists.oasis-open.org on behalf of rich.levinson@oracle.com > wrote: > > Is there any way an OAuth Access Token or Identity Token can be passed > in a XACML Request, and have its contents used in a Policy? > > (I think the answer is no, but checking just in case) > > Thanks, > Rich > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_apps_org_workgroup_portal_my-5Fworkgroups.php&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=nz3Fn66qLx7H4seKWaCIewHybrgY6NYX3PaDZH5uMso&m=2r2E7WDAx-CFmJzNS24SxKemUok_Gm2SxuJ9z8PsU9c&s=NjerES62lCRncIbHwzGUWiBFLm8EzhFh2NKIcn5rt9w&e= > > > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi David, I agree, that is a possible strategy. Where it becomes tricky, I think, is that if there is a multitude of different XACML PDP's that could be called, then each PDP would need to configure an appropriate PIP, along w an appropriate call-out mechanism. In practice, this might be ok, if the XACML PDP's can generally assumed to be from a small set of vendors, where each has provided well-defined mechanisms for implementing/deploying such a PIP. Thanks, Rich On 11/6/2018 11:07 PM, David Brossard wrote: Hi, The token could be parsed by the PEP as suggested in the thread or passed verbatim to the PDP where a PIP could decode it and extract whatever attributes the policy may need. That's what Axiomatics Policy Server does. Note that it's not a PDP's responsibility to validate any token. In federated scenarios, it's quite common to have the PEP pass identity tokens to the PDP. We have customers who do that (SAML and OAuth). David. On Mon, Nov 5, 2018, 9:11 AM rich levinson < rich.levinson@oracle.com wrote: Hi Mohammad, Thanks for the reply. I was thinking that was probably the answer, but wanted to get confirmation. I agree, the PEP probably knows what to do w the token, and if it wants to send info from the token to the PDP, then it needs a vocabulary of AttributeId's in order for a Policy to recognize and process the attribute. Thanks, Rich On 11/5/2018 1:33 PM, Mohammad Jafari wrote: > Although I am not aware of an implementation that supports this, this seems to be a PEP-specific issue. If the PEP can consume an OAuth/OpenID Connect token (which might require doing OAuth Introspection as well) and turn the content into attributes in an XACML request, the rest of the flow should be orthogonal to where these attributes originate from. > > Regards, > Mohammad > > ïOn 2018-11-05, 10:24 AM, xacml@lists.oasis-open.org on behalf of rich levinson < xacml@lists.oasis-open.org on behalf of rich.levinson@oracle.com > wrote: > > Is there any way an OAuth Access Token or Identity Token can be passed > in a XACML Request, and have its contents used in a Policy? > > (I think the answer is no, but checking just in case) > > Thanks, > Rich > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_apps_org_workgroup_portal_my-5Fworkgroups.php&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=nz3Fn66qLx7H4seKWaCIewHybrgY6NYX3PaDZH5uMso&m=2r2E7WDAx-CFmJzNS24SxKemUok_Gm2SxuJ9z8PsU9c&s=NjerES62lCRncIbHwzGUWiBFLm8EzhFh2NKIcn5rt9w&e= > > > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Rich, Is the OAuth token for that of the requestor or does it need to a subject of some kinds? Paul Patrick ïOn 11/5/18, 1:33 PM, "xacml@lists.oasis-open.org on behalf of Mohammad Jafari" <xacml@lists.oasis-open.org on behalf of mohammad.jafari@bookzurman.com> wrote: Although I am not aware of an implementation that supports this, this seems to be a PEP-specific issue. If the PEP can consume an OAuth/OpenID Connect token (which might require doing OAuth Introspection as well) and turn the content into attributes in an XACML request, the rest of the flow should be orthogonal to where these attributes originate from. Regards, Mohammad On 2018-11-05, 10:24 AM, "xacml@lists.oasis-open.org on behalf of rich levinson" <xacml@lists.oasis-open.org on behalf of rich.levinson@oracle.com> wrote: Is there any way an OAuth Access Token or Identity Token can be passed in a XACML Request, and have its contents used in a Policy? (I think the answer is no, but checking just in case) Thanks, Rich --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Hi Paul, In the use case I was considering the PEP had its own OAuth token to enable it to call the PDP, which it puts in the Authorization header, as usual. The, PEP, however, is processing a request from some other subject, and there is more info on that subject in the OAuth token that came in w the Request. So, the PEP is sending its own OAuth token w the request, and putting the user's oauth token in the XACML request, as one big attribute. However, as Mohammad suggested it is better that the PEP extract the attrs from the token rather than expecting the PDP to process it. Technically, it probably could be made to work somehow, but it would be a very custom solution. Thanks, Rich On 11/5/2018 2:12 PM, Paul Patrick wrote: Rich, Is the OAuth token for that of the requestor or does it need to a subject of some kinds? Paul Patrick ïOn 11/5/18, 1:33 PM, "xacml@lists.oasis-open.org on behalf of Mohammad Jafari" <xacml@lists.oasis-open.org on behalf of mohammad.jafari@bookzurman.com> wrote: Although I am not aware of an implementation that supports this, this seems to be a PEP-specific issue. If the PEP can consume an OAuth/OpenID Connect token (which might require doing OAuth Introspection as well) and turn the content into attributes in an XACML request, the rest of the flow should be orthogonal to where these attributes originate from. Regards, Mohammad On 2018-11-05, 10:24 AM, "xacml@lists.oasis-open.org on behalf of rich levinson" <xacml@lists.oasis-open.org on behalf of rich.levinson@oracle.com> wrote: Is there any way an OAuth Access Token or Identity Token can be passed in a XACML Request, and have its contents used in a Policy? (I think the answer is no, but checking just in case) Thanks, Rich --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_apps_org_workgroup_portal_my-5Fworkgroups.php&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=nz3Fn66qLx7H4seKWaCIewHybrgY6NYX3PaDZH5uMso&m=kfFBUjtjJX6OTvaeno3Sef9kIjvaI6bWNYw8oQALdXQ&s=nepFOjvXME8mtWapdrYInTxbr9C_195v0JgPSs_tQQE&e= This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.