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:

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

There are following application types:

Application Type	Description
Web Applications	Ubisecure software modules "Ubisecure Web Applications" installed in web and application servers.
SAML Service Providers	Applications that communicate using SAML protocol with Ubisecure SSO.
ADFS Resource Partners	Applications that are secured with Microsoft ADFS Web Applications.
WS-Federation Application	Applications that communicate using WS-Federation protocol with Ubisecure SSO.
OAuth	OAuth 2.0
Tupas IDP	Applications that communicate using TUPAS protocol with Ubisecure SSO
2.0 Resource Servers	To 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

Field	Description
Technical Name	The 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 Type	The type of this application.
E-mail	This field is informative
Enabled	Enable this application.

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

Generate an Activator file (Web Application)
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.
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

Field	Description
General
Technical Name	Web Application's name in Ubisecure SSO.
Application Type	The type of this application.
Web address	The Web Application's IP-address or URL. This field is informative.
Platform	Web 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.
Description	Describe the Web Application or service behind it. This field is informative.
Contact
E-mail	This field is informative
Status
Enabled	Enable or disable the Web Application
Authentication Session Timeout	Specify 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
ForceReauthentication	Force 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 use	Authentication valid only once. Use this to require a new login event after accessing this application.
Authorization
Authorization Policy	Authorization Policies that are used with this Web Application
Name Mapping	Mappings 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 ID	Web Application identification information. This value is generated automatically for Web Applications or retrieved automatically from the uploaded SAML2 metadata file.
Activate Web Application	For 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 AuthnRequestValidate AuthnRequest signature is NOT required. This allows receipt and processing of unsigned SAML requests. The registered SP metadata must not contain a <KeyDescriptor use="signing"> element.
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:

Task	Description
Update	Update the edited text fields
New	Create a new application
Delete	Delete this Web Application
Rename	Rename 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)

Create a new SAML Service Provider instance to the Ubisecure SSO acting as an IDP.
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.
Exchange SAML 2.0 metadata files (export and import in both Ubisecure SSOs)
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.

WS-Federation

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

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 2013 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.

Create a new application of type OAuth 2.
Click “Upload” and enter OAuth2 JSON formatted client registration metadata (see page Client registration and activation - SSO)
Click “Activate” to generate client_id / client_secret pair and download them as a JSON formatted file.
Configure Allowed To –list and Method –views
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 → Mappings → New 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

Browser not supported