The authorization policy is used to define what data is delivered to the applications behind Web Applications. In practice, the authorization policy adds attributes with name and value to the ticket response message for a web application. No other attributes are delivered to the web application. In this way, the information exposed about a user to applications can be restricted. For data security, it is best practice to send only the minimum amount of information required by the web application. For this reason, it is strongly recommended to use an authorization policy for all web applications.

An authorization policy can be used to assign Application-specific roles to users based on their group membership.

Arbitrary attribute names and values can be sent using the text tag. For example, if an application accepts an attribute called LOGONAME to customize the main screen appearance, this field could be set explicitly to EXAMPLE COMPANY for all users of that application.
Values from a user's directory record can be sent using arbitrary attribute names using the user tag. For example, if an application requires that the user mobile phone number is sent in a variable called MOBILE. User attribute data can optionally be Base64 encoded using the binary tag.

Attributes from Authentication Methods can also be optionally renamed and sent to Web Applications. For example, TUPAS sends Personal Identity Numbers in a field called CUSTID, which can be renamed to PERSONALID before passing to the application.

Authorization policies can be used for Attribute Based Access Control (ABAC) by checking for the presence or absence of a user or method attribute

The same authorization policy can be reused and assigned to many different web applications. A web application can only have one authorization policy assigned to it. Assigning a new Authorization Policy to a web application will replace the existing policy.

The ticket response protocol defines also special semantics for some attribute names, such as "username" and "role". The web application or web application that receives a ticket response message may implement functionality that is based on the ticket response attributes. For example, the Ubisecure BEA WebLogic Application implements J2EE declarative and programmatic authorization based on the values of the username and role attributes. The Ubisecure web application for ASP.NET implements MembershipProvider and RoleProvider based on the values of the username and role attributes, if Membership and Role Providers functions are used.

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


Figure 1: Authorization Policy main view

Object	Description
Ubilogin 2.x/3.0 backwards compatible	Authorization Policy was changed in Ubisecure SSO version 3.1. Please see Release Notes for more information. When this feature is selected, Authorization Policy works as in Ubisecure SSO 3.0. This feature is used to ease the migration process from Ubisecure SSO 3.0. NOTE: By setting this value ON the web application can access all information that is derived from the used authentication method.
Single-Value Attributes	Single-value constraint fails for the defined attribute if more than one distinct value is assigned
Required Attributes	The required constraint fails for the defined attribute if no value is assigned

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.

If no Single-Value or Required attributes are set, no checking is performed on the Authorization Policy. Multiple attribute values with the same name can be sent and null values do not cause authorization failure.

If an attribute name is listed in the Single-Value Attribute list, authorization will fail if more than one attribute value with the same name is listed in the Authorization Policy.

If an attribute name is listed in both the Single-Value Attribute list and the Required Attributes list, that an attribute value with that name must be listed in the Authorization Policy. An attribute with a null value or more than one attribute with that name will cause authorization failure.

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.


Figure 2: Authorization roles

Object	Description
Group	Click Group or System name to edit group object
Update	Edit role field and click Update to update group – role association
Add	Click Add… to create a new association. By default the name of the group is used for the role name. You can change the role name. Any number of associations can be created. A single group may be associated with any number of roles.
Remove	Select group check box and click Remove to remove group – role association.

Attributes

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


Figure 3: Authorization Policy Attributes editor

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.

Attribute	Description
Group	Click group or site name to edit the group object
Name	Name of the authorization attribute
Value	Attribute value. See the syntax below.
Name Format	SAML attribute name format, used in the SAML message. Usually not needed.
Friendly Name	SAML attribute friendly name, used in the SAML message. Usually not needed.
Update	Update the edited fields
Add	Add new group – authorization association for to this authorization policy
Remove	Remove the selected group – authorization association(s)

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 process - SSO and Management customization - SSO → 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.

For more information, refer to Expression language API - SSO.

Note: In the image above, there's the expression that sets the attribute's name to "role", so an attribute with name "name" would not be defined.

Applications

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

Figure 4: The list of applications that the selected authorization policy is applied to

Object	Description
Add	Add a group to the selected authorization policy
Remove	Remove the selected application(s) from this authorization policy

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

Browser not supported