FAQ: What are User Attributes and how are they used in Sentry?


This article defines and describes how user attributes are used in Forum Sentry.  When developing Task Lists, user attributes allow for information to be stored and then used later in the transaction processing flow or with subsequent transactions.  User attributes are used with many types of tasks in Sentry, across virtually all of the Task Types. Depending on the type of user attribute used, the data can be retrieved, manipulated, converted or processed in a variety of ways. 

The data stored in user attributes can come from various sources.  Sentry allows you to select the source of the data when defining the attribute. The source options include the following: 

Request Header
Protocol Header
Response Header
User Attributes
X.509 Attributes
Query Parameter
HTTP Method
Request Path Segments
Full Request URL
Source IP Address
HTTP Status Code
New Session ID
PEM Encoded X509
Full Document


Types of User Attributes

There are multiple types of user attributes in Sentry, with "user attributes" also being one type. Very often all of the different types are considered variations of "User Attributes" both in the product and in the documentation.  For instance, when selecting a user attribute type as the Source of a mapping task in Sentry, the source type will be "user attribute" even if the value is another type of user attribute.  Conversely, when mapping a value to a user attribute the task Target will list the specific type of username attribute. The different types of user attributes are defined below.

User Attributes

User attributes are the most commonly used and can be defined and used within a single transaction (full request and response processing).  Once created, the user attribute can be used in both the request and response processing of the same transaction. Also, if additional transactions are generated within a transaction (e.g. requests to third-party resources), user attributes may be available within these "child-transactions".  Again, user attributes are available only within the context of a single transaction. Once the transaction is completed or terminated, the user attributes defined and used inside the transaction are no longer available for use. 

Example Use Case:

Sentry is being used to secure a REST API. As part of the request task processing, Sentry makes a database query and stores all results as user attributes. These user attribute values are then used for additional filtering and/or are mapped into the request or response payloads or headers within that same transaction.


Identity Attributes

Identity attributes are used within the context of a user session, requiring the use of HTTP session cookies. These are commonly used with SSO use cases that utilize session cookies.  When a user is first authenticated by Sentry, if the use case calls for an HTTP session cookie to be generated, data that is mapped to identity attributes is now available for use in subsequent transactions that include the user's session cookie. Generally, these attributes describe or provide additional information about the user or the user's session.  When used with a database resource, identity attributes can also persist across multiple instances of Sentry. 

Example Use Case:

Sentry is being used for SSO and security of a REST API. Sentry is requiring basic authentication for the login method of this service, with all other methods requiring an HTTP session cookie.  Sentry is communicating with an LDAP server for the basic auth credential validation. When the user's basic auth credentials are validated with the LDAP server, information about the user is returned from the LDAP server (e.g. email, phone, etc). Sentry automatically maps these values to user attributes. A cookie is generated for the user session and returned to the client. When this cookie is provided and validated with subsequent calls, Sentry has access to the user data that is tied to the user session (cookie).  


Aggregation Attributes

Aggregation attributes are used to combine multiple instances of data within one user attribute. Subsequently, when assigning data to these types of attributes, the existing data is kept, and the new data is appended. A comma is used to separate the values.  Aggregation attributes are available within a single transaction only, though the aggregation attribute value could be mapped to an identity attribute when a user session exists.

Example Use Case:

Sentry is being used to secure a SOAP Web service. As part of the request processing, Sentry needs to take values from multiple HTTP headers and map them into an element within the SOAP payload.  Using the "Map Attributes and Headers" task multiple HTTP header values can all be mapped to a single aggregation attribute with multiple mappings.  Then, via the "Map to XML" task the aggregation attribute (source type = user attribute) can be mapped to the SOAP payload. All of the HTTP header values would be mapped into the XML element in a comma delimited format.

Template Attributes

Template attributes (templates) are text-based attributes used to build and manipulate text strings. Templates can be used as the data source for other template attribute and used with text fields in Sentry to automated message creation. Templates are commonly used to break up data based on a pattern, with each segment then available for use by itself. Templates utilize the curly braces { } syntax.

Example Use Case:

Sentry is used to secure a REST API and enforces basic authentication. After the successful authentication, the use case calls for the incoming HTTP Authorization header to be broken up in order to get the password text.  The HTTP Authorization header is a base64 encoded string with the username and password combined and separated with a colon (e.g. username:password). With the "Map Attributes and Headers" task, it is possible to separate the two values into individual user attributes.  For specific instructions on this use case see: https://helpdesk.forumsys.com/entries/94865758-How-To-Breaking-up-the-HTTP-Authorization-Header 


Automatically Mapped User Attributes

There are certain cases where Sentry will automatically map user attribute values, without the need for a task to map these value.  In the following scenarios, Sentry will automatically map user attribute values:

1. SAML SSO - Upon validating of a SAML assertion with the SAML 2.0 Web Browser profile as processed with the User Identity and Access Control task. SAML attribute values are mapped to Sentry user attributes automatically.

2. OAuth - With the attribute call to the OAuth Authorization Server, Sentry maps the response JSON data (typically information about the user) to user attributes.

3. Access Control Policies - With certain Access Control policies, when Sentry calls an external user store to validate user credentials Sentry retrieves data about the user record and maps these values to user attributes automatically. For instance, user data is mapped to attributes with LDAP policies, REST Access Control policies, and SiteMinder policies. 




Article is closed for comments.