...

The main view of authorization policy is presented in Figure 1.

The components of the authorization policy consist of Single-Value and Required constraints. The constraints function is an aid for the application designer and legacy application compatibility. For example, if an application requires a mandatory attribute with the user information, for example email address, this check can be performed already by Ubisecure SSO. Similarly, if an application does not support multiple roles, this can be verified to ensure that only one role is sent during the authorization process. Thus, additional data validation at the application level is avoided.

...

In summary, the default constraint allows 0..N values assigned per attribute, single-value allows 0..1 values, required allows 1..N, and the combination of single-value and required allows 1..1 values.
Authorization will not succeed if any of the constraints fail.

Roles

The Roles view presents a simplified view into the authorization policy where the Site Manager is allowed to manage group – role associations. See the Figure 2.

Attributes

The Attributes view (see Figure 3) presents a more advanced view into the authorization policy.

In this view it is possible to associate groups and attributes of any name. The attribute value assigned to an attribute is entered as an attribute value.

The syntax of the attribute value is as follows:

• text:<string>
→ the value is <string>
• user:<name>
  → the value is evaluated by reading the attribute <name> from the user's directory object. For example, user:uid would return the value of the uid attribute.
• user:<name>;binary
  → LDAP binary option mechanism (http://www.rfc-editor.org/rfc/rfc2251.txt , Authentication and Authorization Processauthorization process and Customizing SSO Management customization → Disabling Context Menu items). The attribute <name> is returned to web applications as Base64 coded string. For example, user:objectGuid;binary would return value such as sFy0xj0cXU6QpjsQRCzG5Q== .
• method:<name>
  → the value is evaluated by reading the attribute <name> assigned by the authentication method component. The availability of method attributes depends on the authentication method implementation. For example, the CUSTID attribute is available with the Tupas 2 authentication method. method:CUSTID would then return the value of the CUSTID attribute from the Tupas 2 authentication process.

Java EL expressions

It is possible to use Java EL expressions in place of attribute values. This enables more complicated techniques available in Java EL syntax for building attribute values, such as concatenation of strings.

The convention used in this Java EL API documentation is:
For top level attributes:

• attributeName [AttributeType]
  → Description of the attribute and its contents.
  • propertyName [PropertyType]
    → Description of the property.
  • methodName(Parameter1Type parameter1Name,…) [ReturnType]
    → Description of the method.

For top level functions:

• prefix:functionName(Parameter1Type parameter1Name,…) [ReturnType]
  → Description of the function

Readable variables

Authorization Policy provides a number of variables whose properties can be read, but not written into. The variables are:

...

• Additionally, in case the Authorization Policy is registered to an OAuth2 –application, the method bean exposes following built-in attributes:
  • grant_type
    → The grant_type of the authentication request that was used for obtaining the token.
  • refresh_token_iat
    → If grant_type is refresh_token then this contains the create time of refresh_token.

...

• value [String]
• handle [String]
• format [String]
• nameQualifier [String]
• spNameQualifier [String]
• spProvidedID [String]

...

Examples of use:

${user.cn}@example.com or ${user.cn[0].concat('@example.com')}

→ Get user’s CN attribute in the user directory and concatenate it with string ‘@example.com’. Both expressions are equivalent.

${sso.template}

→ Sends the name of the current template used

${sso.locale}

→ Sends the currently selected user interface locale

${server.decrypt(user.description)}

→ Sends the currently selected user description decrypted

Modifiable variables

Authorization Policy contains two variables, nameID and attribute, which allow modifications to their underlying models.

• nameID [NameIDBuider]
  → (SAML only) The nameID element of the SAML Assertion to be sent to the application.
  • value(String s) [NameIDBuider]
    → Set the value of the nameID.
  • format(String s) [NameIDBuider]
    → Set the format of the nameID. Valid values are:
    • UNSPECIFIED ­
      → urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    • EMAILADDRESS ­
      → urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    • X509SUBJECTNAME ­
      → urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
    • WINDOWSDOMAINQUALIFIEDNAME ­
      → urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
    • KERBEROS ­
      → urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
    • ENTITY ­
      → urn:oasis:names:tc:SAML:2.0:nameid-format:entity
  • nameQualifier(String s) [NameIDBuider]
    → Set the nameQualifier of the nameID.
  • spNameQualifier(String s) [NameIDBuider]
    → Set the spNameQualifier of the nameID.
  • spProvidedID(String s) [NameIDBuider]
    → Set the spProvidedID of the nameID.

• attribute [AttributeBuilder]
  → The attribute in current authorization policy context, which will be sent to the application.
  • name(String s) [AttributeBuilder]
    → Set the name of the attribute. Note that this overrides the setting in authorization policy itself.
  • values(String s) [AttributeBuilder]
    → Add a value for the attribute.
  • nameFormat(String s) [AttributeBuilder]
    → Set the nameFormat of the attribute. Valid values are:
    • UNSPECIFIED
      → urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
    • URI
      → urn:oasis:names:tc:SAML:2.0:attrname-format:uri
    • BASIC
      → urn:oasis:names:tc:SAML:2.0:attrname-format:basic
  • friendlyName(String s) [AttributeBuilder]
    → Set the friendlyName of the attribute.

Examples of use:

${attribute.name('role').values('manager')}

→ Set a value manager to attribute role.

${nameID.value(user.cn).format(‘x509subjectname’).nameQualifier(user.directory.name)} [PS3] 

→ Set user.cn [PS4] [AÅ5] as the value of the nameID, x509subject as its format and user.directory.name as its nameQualifier. This example shows how the methods can be chained.

${nameID.value(user.cn[0].concat('@example.com')).format('emailaddress')}

→ Set user.cn concatenated with @example.com as the value of nameID and emailaddress as its format.

${user.givenName[0].concat(' ').concat(user.sn[0])}

→ Returns the givenName concatenated with a whitespace character and the user surname.

${eidm['roles'].contains('Users/OrganizationMainUser') ? 'true' : 'false'}

→ Returns “true” if the user has the absolute CustomerID role Users/OrganizationMainUser. Otherwise “false” is returned.

${eidm['roles'].contains('Users/OrganizationMainUser') ? 'useradmin' : 'normaluser'}

→ Returns “useradmin” if the user has the absolute CustomerID role Users/OrganizationMainUser. Otherwise “normaluser” is returned.

Image RemovedNote that in the For more information, refer to Expression Language API.

...

Helper variables

• sha1 [DigestBuilder]
  → Helper for building SHA1 digest.
  • text(String input) [DigestBuilder]
    → Append input string to digest builder.
  • bytes(byte[] input) [DigestBuilder]
    → Append input bytearray to digest builder.
  • guid [UUID]
    → Convert digest to GUID.
  • uuid [UUID]
    → Convert digest to UUID.
• sha256 [DigestBuilder]
  → Helper for building SHA256 digest.
  • text(String input) [DigestBuilder]
    → Append input string to digest builder.
  • bytes(byte[] input) [DigestBuilder]
    → Append input bytearray to digest builder.
  • guid [UUID]
    → Convert digest to GUID.
  • uuid [UUID]
    → Convert digest to UUID.

Examples of use:

${sha256.text(sso.id).uuid}

→ Create SHA256 digest of SSO Session ID and convert the digest to UUID.

Functions

• xss:html(String input) [String]
  → Encode input string for HTML.
• xss:url(String input) [String]
  → Encode input string for URL.
• xss:js(String input) [String]
  → Encode input string for JavaScript.
• xss:json(String input) [String]
  → Encode input string for JSON.
• c14n:text(String input) [String]
  → Encode input string for Text Node in Canonical XML.
• c14n:attr(String name, String input) [String]
  → Encode input string for Attribute Node name in Canonical XML.
• base64:encode(byte[] input) [String]
  → Base64 encode input bytearray.
• md5:encode(byte[] input) [String]
  → md5 encode input bytearray. (Requires SSO 6.9 or newer)
• guid:encode(byte[] input) [String]
  → UUID/GUID encode bytearray. Array’s length must be 16 bytes.
• utf8:bytes(string input) [byte[]]
  → UTF8 encode input string and convert to byte array.
• digest:sha1(byte[] input) [byte[]]
  → SHA1 digest of input bytearray.
• digest:sha256(byte[] input) [byte[]]
  → SHA256 digest of input bytearray.
• re:replace(String input, String regex, String replacement) [String]
  → Replaces the first substring of input string that matches the given regular expression with the given replacement.

Examples of use:

${base64:encode(utf8:bytes(user.uid))} or ${base64:encode(utf8:bytes(user['uid'][0]))}

→ Base64 encode user.uid. Because base64:encode() function requires a bytearray as input parameter, and user.uid is String, it needs to be converted to bytearray using utf8:bytes().

Migration from old expressions to Java EL

All the authorization policy expressions in the old format can be converted to Java EL format. The conversion rules are:

user:property     

...

user:property;binary
→ ${user['property;binary']} or ${encode:base64(user['property;binary'][0])}

user:../property
→ ${user.parent.property}

...

...

text:Literal value
→ Literal value

prefix:xyz
→ ${prefix['xyz']}

Applications

This view shows the web applications where this authorization policy is assigned.

A single authorization policy may be assigned with any number of applications. A single application can be associated with one or zero authorization policies.