Page tree
Skip to end of metadata
Go to start of metadata

Web Applications represent the applications and services that use Ubisecure SSO for authentication and access management.

Figure 1: The list of applications

The first view of Web Applications is presented in Figure 1. There is a list of Web Applications that are configured in this particular site, which means that Ubisecure SSO authenticates all of the applications behind these Web Applications.

The following functions are available:

New Application…Create a new application.
Delete ApplicationSelect a application to be deleted.
Move here…Select applications from others sites to move under the current site.

There are following application types:

Application TypeDescription
Web ApplicationsUbisecure software modules "Ubisecure Web Applications" installed in web and application servers.
SAML Service ProvidersApplications that communicate using SAML protocol with Ubisecure SSO.
ADFS Resource PartnersApplications that are secured with Microsoft ADFS Web Applications.
WS-Federation Application

Applications that communicate using WS-Federation protocol with Ubisecure SSO.

OAuthOAuth 2.0
Tupas IDPApplications that communicate using TUPAS protocol with Ubisecure SSO
2.0 Resource ServersTo configure the applications and services to use Ubisecure SSO as an authentication service, each application must have the required settings configured in the Ubisecure SSO Management application. From SSO Management you can generate Activator files that are needed to activate each Ubisecure Web Application. SAML Service Providers are created by Uploading SAML Metadata to the Web Application. Similar methods are used with ADFS Resource Partners and WS-Federation Applications.

New Application

The window after clicking "New Application…" in Applications view is presented in Figure 2.

Figure 2: Created a new Application
Technical NameThe name of the application. Please use only letters and numbers. Please avoid special characters and letters such as å, ä and ö for compatibility with other systems.
Application TypeThe type of this application.
E-mailThis field is informative
EnabledEnable this application.

After creating an application for the first time, please go through the following steps to make your application works with Ubisecure SSO:

  1. Generate an Activator file (Web Application)
  2. Select the link Allowed Methods: and choose the authentication methods that are available for users logging in to this application or service provider. Please see section Allowed Methods chapter below for details.
  3. Select the link Allowed To: and choose the user groups that are allowed to access this application or service. Please see section Allowed To chapter below for details.

Web Application

Figure 3: Editing Web Application settings

Technical NameWeb Application's name in Ubisecure SSO.
Application TypeThe type of this application.
Web addressThe Web Application's IP-address or URL. This field is informative.
PlatformWeb Application platform such as Java, .NET, IIS, Apache or Notes/Domino. This field is informative.
Template Names

If you have set your own login layout for this Web Application specify the template name here. The corresponding name must be found in the custom/templates.index file. See Login user interface customization - SSO for more information on template use.If left blank, a default template is used.Multiple templates can be specified using whitespace as a separator. The first template listed will be used as the default template. Other templates are available to SAML SP applications implementing template request functionality defined in the API. A SAML SP application cannot request an application that is not listed in this whitelist.

In versions prior to 6.3, this field is called "UAS JSP Template" and only one template name is permitted.

DescriptionDescribe the Web Application or service behind it. This field is informative.
E-mailThis field is informative
EnabledEnable or disable the Web Application
Authentication Session TimeoutSpecify the number of minutes of inactivity after which a user session times out. After the timeout, re-authentication is required. Timeouts are discussed in detail in the Timeout configuration - SSO.The timeout value shown here applies to Ubilogin Web Application integrations using the Ubilogin Ticket Protocol activator file. For SAML SP integrations, this value is indicative only. In both cases, the setting may be overridden in the application or SAML SP settings on the machine where the Web Application is used. These overrides will not be reflected in this value.Note that the value specified for Ubisecure SSO can also override this setting. User session timeout value is determined by the smallest of the following values:
  • Ubisecure SSO timeout
  • Timeout values of those Web Applications that has been used in user session
Single Sign-out Settings
ForceReauthenticationForce authentication regardless of existence of the SSO session. Use this to always prevent single Sign On and force a new login event before accessing the application.
Prevent SSO after useAuthentication valid only once. Use this to require a new login event after accessing this application.
Authorization PolicyAuthorization Policies that are used with this Web Application
Name MappingMappings that are used with this Web Application
Refresh Token Table (OAuth2 only)Refresh token table that is used with this Web Application
ID and Activation
Web Application IDWeb Application identification information. This value is generated automatically for Web Applications or retrieved automatically from the uploaded SAML2 metadata file.
Activate Web ApplicationFor Web Application integrations using the Ubilogin Ticket Protocol, this button will activate the Web Application and generate a Web Application Activator file. The Web Application Activator file must be transferred securely to the target service. For SAML SP integrations using the SAML2 protocol, this button will activate the Web Application as a SAML SP and enable uploading of the SAML SP metadata. SAML SP metadata can also be copy and pasted into the form which opens after pressing this button.
Compatibility (Not for Ubilogin Web Agent)
Application Compatibility Flags
 Click here to expand...
  • EncryptEmbedCertificate  
    XML Encryption: embed recipient encryption certificate with encrypted message.
  • HttpPostResponseSign
     HTTP-Post: Response is not signed. The enclosed Assertion is signed
  • SoapResponseSign
     SOAP, SOAP/Artifact: Response is not signed
  • EncryptAES256
    XML Encryption: Use AES-256 algorithm while encrypting, default is AES-128
  • TokenTypeSAML11
    Use SAML 1.1 Token Type (interop w. Sharepoint) (WS-Federation only)
  • SubjectConfirmationDataRecipient
    SubjectConfirmationData/@Recipient: leave Recipient unassigned (interop w. WIF)
  • AuthenticationContextDeclarationReference
    AuthenticationContext/DeclarationReference: leave DeclarationReference unassigned (interop w. WIF)
  • AssertionSignCertificate
    Response/Assertion: always sign SAML Assertion and embed signer certificate with signature (interop w. Salesforce)
  • ExplicitNotBeforeCondition
    Response/Assertion: sets explicitly the current time as notBefore condition into SAML Assertion, provided that AuthnRequest doesn't define notBefore condition (interop w. Salesforce)
  • ExplicitUnspecifiedAuthnContextClassRef
    Response: adds explicitly the unspecified value to AuthnContextClassRef.
  • AuthnStatementSessionNotOnOrAfter
    AuthnStatement: leave SessionNotOnOrAfter unassigned
Redirect URI validation policy
(OAuth2 and Tupas only)
Specifies the policy on how the redirect URI passed in an authentication request (redirect_uri in OAuth2 and A01Y_RETLINK/A01Y_REJLINK/A01Y_CANLINK in Tupas) are validated against the pre-registered URIs of the client (redirect_uri/redirect_uris in the client metadata in OAuth2 and Tupas).
  • exact: The redirect URI must match exactly a preregistered URI of the client. Specifically, if the redirect URI contains a query part, the query part must also be present in the preregistered URI as well - otherwise they don't match.
  • ignorequery: The query part of the redirect URI is removed and the resulting URI (without a query part) must match a pre-registered URI of the client. Note that the pre-registered URI also must not contain a query part.

The Web Application object contains also the following tasks:

UpdateUpdate the edited text fields
NewCreate a new application
DeleteDelete this Web Application
RenameRename this Web Application. Please note:
  • A Web Application must be reactivated after renaming.
  • The name of an Application is case insensitive. To change the case of an application name, rename the application to a temporary name, and then rename the application again.

SAML Service Provider (Ubisecure Integration Modules)

Please see additional Ubisecure documentation for configuring Ubisecure SAML Service Provider integration modules such as Ubisecure SAML SP for Java or Ubisecure SAML SP for ASP.NET.

SAML Service Provider (Ubisecure SSO as a SAML Service Provider)

  1. Create a new SAML Service Provider instance to the Ubisecure SSO acting as an IDP.
  2. In the Ubisecure SSO acting as a SP, IDP Ubisecure SSO is configured as SAML 2.0 authentication method. Please see more information in page SAML IDP Proxy - SSO.
  3. Exchange SAML 2.0 metadata files (export and import in both Ubisecure SSOs)
  4. Configure Allowed To –list and Method –views in the Ubisecure SSO acting as IDP

SAML Service Provider (Third party SAML Service Providers)

Please contact Ubisecure for configuring Ubisecure SSO with third party SAML 2.0 Service Provider.


Support for WS-Federation is intended for integrating Ubisecure SSO with Microsoft SharePoint 2010.

The optional wres, wctx, wp, wct request parameters are ignored. Sign-out is achieved by terminating application session and calling the Ubisecure SSO sign-out endpoint. No WS-Federation sign-out endpoint is provided in the Ubisecure SSO Metadata.

For more information, please refer to Ubisecure SSO Sharepoint 2010 Integration WS-Federation.

OAuth 2.0 Client

OAuth 2.0 Clients which use Ubisecure SSO as OAuth 2.0 Authorization Server are registered as Applications in Ubisecure SSO Management.

  1. Create a new application of type OAuth 2.

  2. Click “Upload” and enter OAuth2 JSON formatted client registration metadata (see page Client registration and activation - SSO)
  3. Click “Activate” to generate client_id / client_secret pair and download them as a JSON formatted file.
  4. Configure Allowed To –list and Method –views
  5. In case Refresh Tokens are to be requested by the OAuth 2.0 Resource Server or Client, a Refresh Token Table must be associated with the application.
    To create a new Refresh Token Table:
    • Go to: Site → MappingsNew Mapping…
      • Set name, eg. Refresh Token Table 1
      • Set mapping type to OAuth
      • Click OK
    To associate an existing Refresh Token Table with an application:
    • Go to: Site → Mappings → Refresh Token Table 1
      • Select tab “Applications
      • Click Add…
      • Select the application,

        • If needed use Site Navigator to navigate to the site where the application is

Figure 4: Editing application settings for OAuth 2.0

Mobile Connect client

Mobile Connect clients are configured as OAuth2 applications, but with an extra Compatibility Flag MobileConnectLoginHint set (see Figure 5).

The compatibility flag is required, because Mobile Connect clients send Authorization Request with a special version of login_hint, where user's mobile number is prefixed with "ENCR_MSISDN:" followed by RSA-encrypted mobile number, which the client got from Discovery API response. Provided that the encryption is done using SSO's public RSA key, SSO is able to decrypt the encrypted mobile number, if the application doing the Authorization Request has the Compatibility Flag MobileConnectLoginHint set.

Figure 5 Application settings for a Mobile Connect client

Tupas IDP

To use SSO as TUPAS identity provider you need to register a TUPAS IDP application to SSO.

More information on page TUPAS IDP - SSO.

Allowed Methods

In the Allowed Methods view (Figure 6) you can select authentication methods for your application. This application will only be accessible using the authentication methods that are ticked as active in this context view.

Figure 6: Selecting authentication methods for a Web Application
  • Update / Check box
    Enable or disable this authentication method for the current application

Allowed To

In Allowed To view (Figure 7) you can configure the application access control list.

Figure 7: Configuring Web Application access control list
  • Group name
    Select the group for Group view. Selecting the group is allowed only if you are Site Manager in the selected group's site
  • Add
    Add new groups to the access control list
  • Remove
    Select groups to remove from the access control list. Click Remove to finally remove the groups from the access control list
  • No labels