Authorization in SQL integration - SSO

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.

Below is an example of an authorization policy when using SQL database as user a repository.

This information is fetched using the UbiloginAuthorizer –view in MS SQL. They are case sensitive in the Values -field.

New custom attributes should be added into Attributes –table in MS SQL. Built-in attributes can be found in Users –table.

Once the Authorization Policy is ready, remember to assign in to the required Application.