Check for more data types when parsing Claim Type Values from Access Tokens

[seantleonard]

Issue Summary

This issue applies to parsing database policies from authorization permissions configuration. Database policies may utilize authenticated user claims when building a database query predicate to restrict query results.

Issue Resolution Criteria

The authorization resolver should attempt to parse authenticated user claims (i.e. access token/ JWT claims) into the value type of the database field to which they are being applied.

• "@claims.id eq @item.id" will attempt to convert the token claim id of whatever JSON value type it may be in the token, into the (CLR) value type of the field id.

Claims are typically found in a JWT token (JSON Web Token) provided in http headers by the client.
JSON data types enumerated below as defined in http://json-schema.org/understanding-json-schema/reference/type.html

• string
• number
• integer
• object
• array
• boolean
• null

Background

i.e. GUID, if applicable per this comment thread:
#895 (comment)

data-api-builder/src/Service/Authorization/AuthorizationResolver.cs

Lines 553 to 564 in d5820d4

	switch (claim.ValueType)
	{
	case ClaimValueTypes.String:
	return $"('{claim.Value}')";
	case ClaimValueTypes.Boolean:
	case ClaimValueTypes.Integer32:
	case ClaimValueTypes.Integer64:
	case ClaimValueTypes.Double:
	return $"({claim.Value})";
	default:
	// One of the claims in the request had unsupported data type.
	throw new DataApiBuilderException(

The above PR discussion references the GUID type, which does not have a matching JSON value type. In a JWT token, a GUID will exist as a string. So, conversion from a string to GUID value type is required.

Referenced Issue

From #843:

If X-MS-CLIENT-PRINCIPAL contains the following (base64-encoded) JSON

{  
  "identityProvider": "test",
  "userId": "12345",
  "userDetails": "john@contoso.com",
  "userRoles": ["role1", "role2", "author"],
  "claims": [{
    "typ": "SeriesId",
    "val": 10000
  }]
}

it will not be correctly interpreted as a valid client principal and thus the request will not be considered authenticated. The issue is with the val element, that contains an integer and not a string. Changing the value integer value 10000 into the string value "10000" allows authentication to work as expected

[seantleonard]

updated issue with better defined purpose and criteria for resolution.

[Aniruddh25]

Dependent on #843