Back to Search Back to Search Results

TD Security Configuration

1 Portal Security Configuration

Organizations can configure OpenID Connect authorization providers, SAML 2.0 identity providers and/or LDAP repositories to secure portals owned by the organization. An organization may have any number of connected authentication services, but a given portal may only be associated with a single authentication system.
Note: Security, LDAP, SAML 2.0 and OpenID Connect are all very complex. A deep overview of these subjects is outside the scope of this document. Users attempting to set up security configurations should have knowledge of how LDAP, SAML 2.0, and/or OpenID Connect function before reading this section.
Organization Security Configuration Page

1.1 Configuring OpenID Security Profiles

Note: Oberon Technologies cannot guarantee that all OpenID Connect providers are compatible with Titania Delivery and its underlying OpenID framework and implementation. Experience has shown that different software producers have implemented the OpenID and OAuth2 standards in slightly different ways that may be incompatible with Titania Delivery. The OpenID providers that are known to have been configured to work with Titania Delivery are:
  • Microsoft ADFS
  • Salesforce
Note: The Titania Delivery OpenID framework may not work with Symantec SiteMinder v12.8 OpenID providers, due to an incompatibility in handling some values during the protocol exchange.
Note: Current customers who intend to use OpenID authorization should contact Titania Product Support (through their support portal) to arrange testing on a non-production Titania Delivery platform, to verify that their provider and configuration will work as expected. New customers who intend to use OpenID authorization should contact their project manager for support.
Note: Oberon Technologies does not provide detailed technical support for setting up and configuring a customer's OpenID provider.
A Titania Delivery system administrator will need the following configuration items in order to set up an OpenID provider. Consult your OpenId provider’s documentation for details on how to create and register a Titania Delivery instance as an authenticated client application (or relying party).

  1. The “/.well-known” endpoint — this is a provider-specific URL which returns essential information about an OpenID application. Some examples include “https://[server name and app ids]/.well-known/openid-configuration, where [server name and app ids] is the provider host name plus any identifiers specific to the desired client application. Each OpenID provider and each registered client application on the provider will be unique.

  2. The Client Id is generated by the authorization provider when a client application is created by your OpenID system administrator.

    Note: Some providers allow Client Id values to be user-generated.

  3. The Client Secret is also generated by the provider when the client application is created.

  4. When configuring the provider, the OpenID system administrator must specify the redirection URI for your Titania Delivery platform. This URI must conform to the following pattern: https://[hostname]/login/oauth2/code where [hostname] is your Titania Delivery server platform.

    Note: OpenID providers use various names for the redirection URI, such as “Callback URLs” or “Authorized redirect URIs”.

This section describes the configuration of OpenID providers with Titania Delivery. The details of registering OpenID clients such as Titania Delivery vary according to the provider. Titania Delivery follows the OpenID Connect 1.0 specification.
  1. Go to, or create, a Titania Delivery Organization to add a new authentication system.
  2. Click Authentication Systems.
  3. In the Portal Authentication Systems page, click New in the OpenID Providers section.
    The OpenID Provider window will appear.
  4. In the Display Name field, enter a label for the OpenID provider. This label should be unique among all OpenID profiles on your TD platform, to avoid ambiguity when selecting a security profile for a portal.
  5. In the Issuer field, enter your OpenID Provider Issuer URL. (See Section 2 of the OpenID Connect 1.0 specification and your OpenID provider documentation.)
    Note: TD expects to find a JSON document describing the OpenID provider configuration by concatenating /.well-known/openid-configuration to this URL as described in Section 4 of the OpenID Connect 1.0 specification. DO NOT INCLUDE the /.well-known/openid-configuration in the issuer URL.
  6. In the Client ID field, enter the Client Id created or generated when the client application was created by your OpenID system administrator.
  7. In the Client Secret field, enter the Client Secret generated when the client application was created by your OpenID system administrator.
  8. If your OIDC provider requires custom scopes to process an authorization request, enter them in the Custom scopes field, separated by spaces. Otherwise, leave this field blank. If present, custom scopes will be appended to the default scopes used for the OpenID Connect protocol.
  9. Click the Save button.
    Note: Before saving the configuration, the system will validate the issuer URL. If the URL cannot be reached, the configuration will not be saved.
Titania Delivery will display the newly-created OpenID Connect provider in the Portal Authentication Systems window and will store the configuration information, dynamically updating the server configuration.
Note: If the configuration information needs to change, the Save button will update the existing OpenID configuration.
    Note:

  • The OpenID administrator must ensure the authorization provider supports the “openid” scope and either the “email” or the “upn” scopes. This may require modifying the default configuration with some OpenId Connect providers when setting up a client application.

  • The OpenID administrator must ensure the authorization provider complies with Authorization Code flow as described in Section 2.1.5.1 End-User Grants Authorization and RFC 6749.

1.2 Configuring SAML Security Profiles

How to set up a Titania Delivery security profile to use an external SAML IdP for portal authentication.
Note: Titania Delivery administrators who are creating SAML security configurations should have a basic understanding of SAML 2.0 as described in the SAML V2.0 Technical Overview. Titania administrators must work with a SAML administrator in their organization who can configure the chosen SAML Identity Provider (IdP) application to register Titania Delivery as a SAML Service Provider (SP), and configure it appropriately. The details of registering service providers with an IdP varies by vendor; consult your IdP's documentation for details on how to register and configure service providers.
Overview

The high-level steps to set up a TD security configuration for a SAML IdP are:

  1. (Titania Administrator) Export the Titania Delivery SAML Service Provider metadata as an XML file. This is the "SP metadata".
  2. (SAML Administrator) Register Titania Delivery with the chosen SAML IdP, using the information in the SP metadata, and additional requirements as specified in SAML Identity Provider SSO Configuration.
  3. (SAML Administrator) Export the "federated metadata" from the IdP, or provide the URL for the federated metadata.
    Note: Alternatively, the required information can be entered manually in the TD security configuration form. See Manual SAML Security Configuration.
  4. (Titania Administrator) Set up the SAML security profile in Titania Delivery, either manually, or by importing the federated metadata.
  5. (Titania Administrator) As needed, associate the SAML security configuration with portal(s) that will use this IdP for authentication. See Portal Security

SP Metadata and certificates

The Organizations ⇒ Authentication Systems admin page provides persistent links to the following SAML resources, under the SAML 2.0 Identity Providers heading:

Service Provider Metadata
The Entity Descriptor (SP metadata) XML for Titania Delivery, for use in configuring IdPs to accept authentication requests from Titania Delivery. The URL for this metadata is persistent for the Titania Delivery platform, and can be registered with IdP services that support automatic metadata refresh.
SP Signing Certificate
The certificate corresponding to the key that will be used by Titania Delivery when signing authentication requests.
SP Encryption Certificate
The certificate that must be used by Identity Providers when encrypting authentication responses being sent to Titania Delivery.
Important: The keys used by all SAML services generally have expiration dates of 6 months to 1 year, and will be replaced over time. Be sure to consult your Identity Providers and Titania Software to ensure that keys used for SAML authentication remain up-to-date.
Entity ID and IdP-Initiated SSO

If you plan to use IdP-initiated SSO (as described in SAML V2.0 Technical Overview, Section 5.1.1), you should configure your SAML identity provider to send SAML SSO <Response> messages with a form control or URL query parameter named RelayState whose value is the fully-qualified URL of the requested portal. Otherwise, if there are multiple SAML IdP Configurations with the same Entity ID on the TD platform (across all organizations), Titania Delivery may fail to fulfill the request. If the RelayState parameter is not provided, then Titania Delivery will not display a portal page.

If you create SAML IdP Configurations with duplicate Entity IDs, and do not use IdP-initiated SSO, this will not be a problem. Duplicate Entity IDs will typically be created automatically when importing IdP federated metadata from the same provider.

Additional SAML user assertions

SAML IdPs may be configured to include additional assertions (properties) about the user with a successful authentication response. These properties are stored with the portal user object, and are available for use in portal themes and for dynamic content filtering.

Is it possible for the authentication request to specify what properties to include in the response, or is it entirely up to the IdP?

SAML user assertions do not need to be registered with Titania Delivery in advance. All such assertions in an authentication response are put into a map object, using the SAML technical name as the key. This map is available as the user.properties property.

Provide example of Assertion markup and freemarker code to access user property.

Microsoft ADFS IdP requirements

From TD version 4.5.0 and on, Microsoft ADFS SAML IdP Relying Party Trusts property must be set as described below.

An ADFS administrator must use a PowerShell command to modify the SamlResponseSignature property of any relevant Relying Party Trusts.

Use the following PowerShell command to view the property: 

Get-AdfsRelyingPartyTrust -Name [Relying Party Trust Name]
where [Relying Party Trust Name] is the Display Name of the trust. Search for the value of the SamlResponseSignature property. The required value is MessageAndAssertion.

Use the following PowerShell command to set the property: 

Set-AdfsRelyingPartyTrust -Name [Relying Party Trust Name] -SamlResponseSignature MessageAndAssertion
where [Relying Party Trust Name] is the Display Name of the trust.

1.2.1 Manual SAML Security Configuration

Manually creating a SAML security configuration.

From the Organizations ⇒ Authentication Systems page in the TD admin application, click the New... button next to the SAML 2.0 Identity Providers heading. This dialog allows the manual configuration of the Identity Provider settings.

SAML Identity Provider Details Dialog
Name
The display name for the configuration. This is not used in the authentication process, and is simply a label for the configuration.
Organization Name
The Organization Name for the IdP.
Entity ID
The entity ID for the IdP service.
NameID Policy
The NameID policy to specify when making authentication requests with the IdP.
Note: Not all Identity Provider implementations honor the NameID policy specified in authentication requests. It is often the case that the NameID value must be separately configured in the Identity Provider service's configuration settings.
Important: The NameID provided by the IdP is used as the persistent user ID within the portal for purposes of tracking comments made by the user, and assemblies owned by the user. SAML 2.0 allows for transient NameIDs, such that every authentication results in a different value for the same user. While this will work for authentication purposes, Titania Delivery will treat each new session as if it were a new user, and so the ability to manage assemblies and comments from previous sessions will be lost. In general, we strongly recommend using a persistent NameID value, such as e-mail address or other persistent ID.
Display Name Attribute
The attribute that will be included in any authorization response which corresponds to the user's display name.
Single Sign-On (SSO) Endpoint URL
The URL that the IdP service uses to accept authentication requests. This may be found in the federated metadata provided by the IdP, or directly from the IdP configuration.
Request Mode (SSO)
The mode to use when issuing authentication requests to the IdP service. It is recommended to use "HTTP POST".
Single Log Out (SLO) Endpoint URL
The URL that the IdP service uses to accept logout requests. This is typically the same URL as the Single Sign-On Endpoint URL. It may be found in the federated metadata provided by the IdP, or directly from the IdP configuration.
Request Mode (SLO)
The mode to use when issuing logout requests to the IdP service. It is recommended to use "HTTP POST".
Sign Authorization Requests
When checked, authorization requests sent to the IdP will be signed using the key corresponding to Titania Delivery's signing certificate. It is recommended always to sign requests, for greatest security.
X.509 Certificate String
The Base64-encoded string representing the certificate that will be used to verify signed values in authentication responses provided by the IdP. This value is provided in the IdP''s federated metadata, or it can be obtained directly from the IdP configuration. It is recommended to configure your IdP to sign responses, for greatest security.

1.2.2 Importing SAML IdP Settings

SAML IdP service provider settings may be exported from the IdP as a "federated metadata" XML file; alternatively, it may be retrieved from a specified URL on the IdP.

To import the federated metadata and automatically configure the TD security profile, select the Organizations ⇒ Authentication Systems page in the TD admin application, and click the Import... link next to the SAML 2.0 Identity Providers heading.

SAML IdP Import Dialog

SAML federated metadata can be imported either from a public URL or by uploading the metadata file. Select the appropriate radio button and provide the URL or file. Then click OK.

Note: The Entity Descriptor markup will not include the display name property, which is required for Titania Delivery to function as expected. After importing the IdP metadata, open the resulting details and provide the appropriate value in the Display Name Attribute setting. By default, Titania Delivery uses displayName for this purpose if available, and will use the provided NameID value otherwise.

1.2.3 SAML Identity Provider SSO Configuration

Configuring a SAML Single Sign-On (SSO) provider for security and compatibility with Titania Delivery.

Best practices for configuring a SAML identity provider to register Titania Delivery as a service provider.

Signing Requests and Responses

Requiring signed requests is one way the IdP can verify that requests are sent from a trusted relying party. The IdP should configured to required signed requests, and to send signed responses.

Assertion Consumer Service URL

The Assertion Consumer Service of a SAML relying party is responsible for receiving and processing SAML responses . On the Titania Delivery platform, the assertion consumer service is available at a URL like https://[td-hostname]/portals/saml2/assert. The <AssertionConsumerServiceURL> element of the TD service provider metadata XML file contains the specific value for each TD platform. When registering Titania Delivery as a service provider with your IdP, the configuration will include this URL, which is used to route responses from the IdP to Titania Delivery.

The assertion consumer service URL provided in the SP metadata may be over-ridden in SAML authentication requests to the IdP. All requests originating from Titania Delivery will include an <AuthnRequest>/@@AssertionConsumerServiceURL attribute with a value like https://[td-hostname]/portals/saml2/assert/[registration-id], where [registration-id] is an arbitrary alphanumeric string. The SAML 2.0 Core specification requires IdPs to:

  1. Recognize URLs like this as valid assertion consumer service URLs for this service provider. Different IdPs will have different ways of configuring this. It might be possible to define the valid assertion consumer service URLs using a pattern with a wildcard, such as https://[td-hostname]/portals/saml2/assert/*. In other IdPs, if the requests are signed, they will use the assertion consumer service URL provided in the request.
  2. Return the authorization reponse to the URL provided in the request (including the registration-id).

RelayState

The SAML 2.0 Bindings specification defines a "RelayState" mechanism for preserving state between SAML entities during message exchanges. The specification requires responders to faithfully include any received relay state data in their response. In HTTP POST and redirect protocols, relay state is transmitted as a URL-encoded value of a URL parameter (or form control) named "RelayState".

Authentication requests originating from Titania Delivery will include a "RelayState" URL parameter (or form control) with a value representing the secured portal URL. This value must be returned with the authorization response.

For IdP-initiated authentication, the SAML authorization response sent to the assertion consumer service must include a "RelayState" parameter with the URL-encoded value of the URL of the requested portal.

1.3 Configuring LDAP Connections

Titania Delivery connects to your authentication server via the LDAP protocol. The specific configuration can be set up in the administrative application.

LDAP configurations are associated with Organizations. To establish an LDAP connection, select the Security category of the organization and click the New... link next to the LDAP Connections header to raise the LDAP Security Configuration dialog.

LDAP Configuration Dialog
Name

The field names on this page do not appear in bold like in other sections.  For example, see Part III.1.

A name identifying the LDAP connection.
Host
The hostname or IP address of the LDAP protocol listener on the directory server.
Port
The port number on which to connect to the directory server.
Use Secure Connection
Whether to use LDAPS to communicate with the directory server.
Base DN
The full Distinguished Name of the node within the directory server.
Admin User DN
The full Distinguished Name of the account Titania Delivery will use to connect to the directory server.
Admin Password
The password for the account identified in the Admin User DN.
Additional User DN
Additional Distinguished Name segments to prepend to Base DN when querying the directory server for users.
User Name Property
The property in the directory system that will be used to test the user name for authentication attempts.
Additional User Filter
An LDAP query to append to the default query used when searching for users in addition to the User Name Property.
User Properties
Additional object properties from the directory server to retrieve when a user logs in. These properties will be made available in the properties collection on the object available to all portal pages once a user logs in.
Additional Group DN
Additional Distinguished Name segments to prepend to Base DN when querying the directory server for user groups.
Group Name Property
The property in the directory system that will be used as the group's name.
Additional Group Filter
An LDAP query to append to the default query used when fetching groups.
Group Membership Determination
This is the method used to determine whether a user is a member of a group.
None
No group membership checks will be performed, and group-based access control will be disabled.
User Attribute
Use this when the directory server supports a dynamic property on the user object listing the groups to which a user belongs. For example, the memberOf property in Active Directory.
Group Query
Use this when the directory server does not support any sort of memberOf property. When group-based access control is configured for a portal, Titania Delivery will first authenticate the user, and then execute a second query to verify that the user is a member of the specified group.

1.4 Portal Security

A portal can be configured to allow or require a user to authenticate before being granted access.

You assign a security system to a portal using the portal's Authentication tab.

Portal Security Association

The list of available security configurations is populated by those available in the organization that owns the portal, as well as those set up in the System Administrators organization, which are global. Once the portal is associated with a security configuration, additional details can be specified.

If using an LDAP-based configuration, you can specify the lists of users and/or organizations within the repository that will have access to the portal. You can also specify which users should be granted Comment Moderator rights within the portal, meaning that they can edit, delete, and set dispositions of other users' comments.

Note: Only Owners and Administrators in the security configuration's organization can modify the LDAP allowed users and organizations. If the security configuration was defined in the System Administrators organization, only members of that organization will have this privilege.

If using an OpenID-based or SAML-based service, you can only specify the list of NameID values to be granted comment moderator rights.

If using OpenID authentication, you may select more than one OpenID provider for the portal. The portal theme must include a template file at pages/oauth2login.ftl, which will show the available OpenID providers from which the user may choose one. Theme developers may customize the style of this page. A default template is provided in the Titania Default Theme.

To unset all security providers for the portal, click the Delete button.

After making changes, click the Save button.

The default portal theme includes a page that can be used to review the current session's security information, including the authenticated user, their properties, and the results of the dynamic security script, including print() output. This page can be included into any portal theme, though it is generally not linked to from any of the main pages, and primarily exists as a debugging tool. It can be found at the URL /portalUrlPath/pages/userInfo. This page can be used to view the properties and, for SAML 2.0, NameID value for the currently logged-in user, as well as details about the dynamic filter script output, if any.

1.4.1 OIDC Bearer Tokens

Portal requests may be authenticated by means of an OIDC Bearer token.

For portals that use OpenID Connect (OIDC) authentication, portal requests may use Bearer tokens to authenticate. The OIDC provider must support token generation and validation (and optionally, refreshing tokens). The process for configuring OIDC providers for token support will vary with the provider. Consult your OIDC provider administrative documentation for details and requirements. The OIDC client registration must support scopes "openid" and "offline_access", and conform to the OAuth2 "Authorization Code" flow. Titania Delivery only supports OIDC bearer tokens in JWT (JSON Web Token) format.

The OIDC security configuration must be set up in an organization accessible by the portal, and the portal must be configured to use the OIDC security configuration.

The process for using Bearer tokens is:

  1. A third-party application (or web page) authenticates itself with the OIDC provider.
  2. The client application obtains a bearer token from the OIDC provider.
  3. The client makes an HTTP request to a portal URL, and includes the bearer token. The bearer token may be attached to the request in one of these ways:
    • Put the bearer token in the Authorization request header, preceded by the the literal string "Bearer ". (This is the most secure, and preferred, method. See "Authorization Request Header Field" section in the "OAuth 2.0 Bearer Token Usage" RFC for additional details.)
    • In a POST request, add the bearer token as the value of a form url-encoded parameter named "access_token" in the body of the request. (This is less secure, and should be used only when the client application is unable to set request headers. See "Form-Encoded Body Parameter" section in the "OAuth 2.0 Bearer Token Usage" RFC for additional details.)
    • In a GET or POST request, add the bearer token as the value of a URL query parameter named "access_token".
      Note: This is considered a higher security risk than the other methods. By default, Titania Delivery does not support this method. Customers may request Oberon Technologies to enable this method for their site after acknowledging and accepting the security risks. (See "URI Query Parameter" section in the "OAuth 2.0 Bearer Token Usage" RFC for additional details.)
  4. Titania Delivery will validate the token using information from the OIDC provider. If the token is valid, the request will be processed normally. If the token has expired, the portal will attempt to obtain a fresh token, and, if successful, will return a 4xx HTTP response with the new token in the WWW-Authenticate response header. The client application may resubmit the request with the new token, or take other action. If the token cannot be validated, a 4xx HTTP response will be returned to the client.

The following industry standard specifications provide additional details about the processes and entities described here:

1.4.2 Troubleshooting SAML Authentication

Tips for troubleshooting SAML authentication problems.

The Titania Delivery SAML authentication framework is designed to implement the preferred security recommendations available in the SAML protocol. There are a variety of SAML Identity Provider (IdP) applications available. If your SAML IdP supports the recommended security features that TD uses, it will be possible to configure TD to use your SAML IdP.

Note: Each Titania Delivery customer is responsible for configuring their SAML provider with details of the Titania Delivery portal(s) that will use SAML authentication. The user interface techniques and terminology for configuring IdPs will be different for each IdP vendor, but the authentication protocols and messages used by your IdP and Titania Delivery are standardized in accordance with the SAML 2.0 specification.
SAML Tracer

SAML protocol tracers are available as plugins or addons for various browsers. One such tool is SAML Tracer for Mozilla Firefox. Oberon Technologies make no representation or guarantees about the safety or suitability of this tool. Consult your enterprise IT security policies before installing or using any SAML tracer plugin.

A SAML tracer can display the details of the various SAML requests, responses, and redirects that occur during SAML authentication. This can help an experienced SAML administrator identify the possible causes of a SAML authentication problem.

Troubleshooting
  1. Review the configuration of the SAML security profile that is associated to the portal. Be aware that many security profiles with similar settings and names may have been defined on your system.
  2. Check the IdP configuration for the IdP to verify that the settings agree with settings in the SAML security profile, and meet the requirements described in SAML Identity Provider SSO Configuration.
  3. Make sure all X.509 security certificates are up to date on your SAML IdP. Instructions for checking security certificates should be available in your IdP's administration guide.
  4. Do the certificate strings on Titania Delivery's SAML configuration form match the expected data configured (or auto-configured) on your SAML IdP? Some IdP’s can be configured to auto-update if Titania’s “Service Provider Metadata” changes.
  5. Does the IdP’s X.509 certificate string match the SAML configuration on Titania Delivery?

1.5 Secure Portal Session Timeout

System behavior when a secure portal session times out due to inactivity.

By default, all Titania Delivery portal sessions time out after 15 minutes of inactivity. When the portal is unsecured, or the user is browsing anonymously, a new session will automatically be created when the user navigates to a portal page after a timeout. The user will typically not notice any interruption of service.

Contact Oberon Support to request a change to the portal timeout value. Any change will apply to all portals on the site.

When the user is authenticated in a portal session that times out, the behavior may be different, depending on what authentication method is used and how the system is configured.

Note: To reduce the risk of unauthorized portal access, all portal pages should include a "Logout" button, and users should be advised to log out of the portal before leaving the site. Do not rely on session timeouts or closing the browser window.
OpenID Connect authentication

When an OpenID-authenticated portal session expires, the system will automatically reauthenticate a new session.

SAML2 authentication

In the default deployment configuration, when a SAML-authenticated portal session times out, the system will automatically reauthenticate a new session with the SAML IdP.

The default behavior may not be desired in all cases, because it raises the risk of "tailgating" access by unauthorized users. For example, if a secure portal is available on a public computer, and one user fails to log out of the portal, another user with different privileges could subsequently gain access to the portal, even after the session has timed out.

Customers may request Titania Support to change the deployment configuration for their site, to force re-authentication after session timeouts. This change will apply to all SAML-authenticated portals on the site. Users will be challenged for login credentials every time they attempt to navigate to a portal page after the session has timed out.

LDAP authentication

When an LDAP-authenticated portal session expires, the user will be challenged to re-enter credentials when navigating to a new portal page or refreshing the current page.

1.6 Dynamic Content Filtering

In addition to global metadata filters, administrators can implement dynamic filtering based on a user's identity using Javascript.

The script will be given a user variable containing the identity of the authenticated user, if any. If there is no user, it will be null. The script should end with a return statement returning one of the following.

  • A string containing a search query for content access filtering. This query will be included in all content queries during the user's session. The user will only be able to see content that matches the given filter query.
  • false, in which case the user will be prevented from accessing the portal entirely.
  • null or undefined (or no return statement at all), which will result in no additional filtering being applied.
Important: Dynamic filtering does not apply to monolithic views of DITA map content. This means if there are cases where the topics within a DITA map will be visible to some users but not others, you should disable the Monolithic Map feature in your portal theme(s).
Interrogating the User's Properties

The identity provider may provide additional properties associated with the authenticated user. This script can access those properties to make decisions about what content the user can access using the following properties of the user object.

Map properties
The user properties pulled from the authentication service. For SAML-secured and OpenID-secured portals, this will contain whatever attributes were included in the authentication response message sent by the Identity Provider. For LDAP-secured portals, this will contain the properties listed in the LDAP connection configuration. NOTE: This collection allows for multi-valued properties, so values are arrays, not single values. Properties with single values will be lists of size 1.
boolean hasProperty( String name, String value)
Tests whether there exists a property with the given name containing the given value. If the value is not specified, this method tests whether the property exists.

The script also provides the following utility functions.

escape(str)
Escapes reserved characters in the given string so that it can be used inside a search string.
quote(str)
Like escape(), but additionally wraps the text in quotes.
print(str)
A degugging function that prints the given string to the execution log. See below for how to read the log output.

The provided script will be executed at the following times.

  • If the portal supports anonymous access, the script will be run when a user first accesses the portal, with a null value for user.
  • Immediately after a user authenticates with the portal, with the user populated with the username and properties provided by the identity provider.
  • If the portal supports anonymous access, the script will also be run after an authenticated user logs out, again with null for user.
Script Testing

Once the script is entered, it can be tested using the Test Script section of the page, which allows you to construct a user and their properties to run through your filter function.

  1. Specify whether or not an anonymous user will be used.
  2. Specify the username and properties for the dummy user, if desired.
    Note: User properties are multi-valued. The provided interface allows you to add multiple values for properties (smaller buttons), as well as adding and removing additional properties (larger buttons).
  3. Click the Test Script button.

The script will be executed on the server, and the results of the script will be printed below the form, including strings passed to the print() function.

The /pages/userInfo page in the default portal theme can also be used to view the script output for the currently-authenticated user in a live portal.