The authorization policy is used to define what data is delivered to the applications behind Web Agents. In practice, the authorization policy adds attributes with name and value to the ticket response message for a web agent. No other attributes are delivered to the web agent. 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 agent. For this reason, it is strongly recommended to use an authorization policy for all web agents.
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 agents. A web agent can only have one authorization policy assigned to it. Assigning a new Authorization Policy to a Web Agent will replace the existing policy.
The ticket response protocol defines also special semantics for some attribute names, such as "username" and "role". The web agent 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 Agent implements J2EE declarative and programmatic authorization based on the values of the username and role attributes. The Ubisecure Web Agent 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.
| Figure 1. Attributes in Authorization Policy |
This information is fetched using the UbiloginAuthorizer –view in MS SQL. They are case sensitive in the Values -field.
|
|---|
Figure 2. UbiloginAuthorizer –view in MS SQL |
New custom attributes should be added into Attributes –table in MS SQL. Built-in attributes can be found in Users –table.
|
|---|
Figure 3. Attributes –table in MS SQL |
Once the Authorization Policy is ready, remember to assign in to the required Agent.
|
|---|
Figure 4. Attributes at the application when successfully signed in |
