User Attribute-based Scope Validation with XACML ScopeValidator

1. Attribute-based Scope Validation based on user attributes from local user store

This improvement is supported for WSO2IS-5.7.0 Wum updated pack.

Inorder to get user attribute from local userstore, the attributeId should be as the claimURI and category Id should be “urn:oasis:names:tc:xacml:1.0:subject-category:access-subject”

For an example, if the Administrator wants to give the access token only if the user has the role admin. Then in the XACML policy,

attributeId : http://wso2.org/claims/role

category: urn:oasis:names:tc:xacml:1.0:subject-category:access-subject

Then PDP will find this missing role attributes value from PIP (In WSO2 Identity Server DefaultAttributeFInder PIP is used to get user attributes from local userstore).

A sample XACML Policy is shown below.

2. Attribute-based Scope Validation based on user attributes from context.

Prerequisites:

The user attributes that need to be validated using XACML policy should be requested by the service provider in WSO2 Identity server.

Navigate to Main>Service Provider > Claim Configuration and add the requested claims.

In this situation, the user attributes will be taken from the context.

Sample XACML policy to pickup user attributes from the context

A new category URI is introduced to support for federated users’ user attributes which are in sp claim dialect.

To validate a XACML policy based on user attributes in the context, claims should be requested from service provider. If it is OIDC, claims are always in OIDC dialect, If it is OAuth, and will be in sp's requested claim dialect. That's why spclaim category is used in PEP.

Since the claims are in remote claim Dialect, the categoryURI will be to “http://wso2.org/identity/user/claim/sp” and attribute Id will be as the claimURI requested by service provider.That depends on the claim configurations under in service provider configuration.

An XACML request is created with the attributeId , categoryURI and the userattribute value taken from context. Then it will be sent to the PDP and PDP will resolve that dynamically without pulling user attributes from userstore.

This can be used for federated users as well. The attribute id depends on the claimURI. If you have done any claim mapping, the attributeId will correspond service provider claim URI.

Even for federated users, if there is a missing claim in the XACMLPolicy, the PDP will search the userstore via DefaultAttributeFinder. It is an overhead. In order to avoid that, we will handle this in DefaultAttributeFinder PIP by setting a new flag for federated users in PEPs. Then DefaultAttributeFinderPIP will read the flag from the XACML context and refrain from pulling user attributes from userstore if the flag is set. In order to have backward compatibility,

 org.wso2.carbon.identity.entitlement.pip.DefaultAttributeFinder.1=MapFederatedUsersToLocal,true

This config should be added to entitlement.properties file located in <IS_HOME>/repository/conf/ directory.

If this conf is enabled, that means, federated users are mapped to local users. So use local userstore to get the attribute value for a missing attribute of a federated user.

If this conf is disabled, then, federated users are not mapped to local users. When there is a missing attribute, do not search in local userstore to get the attribute value for a missing attribute.