Authentication method hiding rules - SSO

A template may contain the methodmenu.rules property. That property defines the file that contains the actual method hiding rules. Those rules are described in this chapter. The idea behind these method hiding rules is that some methods are not shown when the web application is in a certain site. Single sign-on would still be possible with the hidden methods, but they could not be used for initial authentication with the specific application. Because method hiding is defined recursively and some sites might require exceptions to that, it is possible to override method hiding using these rules. You may specify as many rules as you like.

• dn → This property defines the site for the hiding rule. The sites are specified using the site's distinguished name (dn) in the directory. Requires Ubisecure SSO version 6.1.0 or higher.

Example: dn: ou=Subsite,ou=Site,cn=Ubisecure,dc=com,dc=example

• visible → This property defines the methods that should be visible. Any method which is not in listed here, will be hidden. This property enables the cancelation of another rule that would hide the method for the specified site. Note that you cannot make visible any methods that would not be visible if no hiding rules would have been given. The methods are entered as a comma separated list. Requires Ubisecure SSO version 6.1.0 or higher.

Example: visible: tupas.handelsbanken.2, tupas.nordea.2

• hide → This property defines the methods that are to be hidden. The methods are entered as a comma separated list. Requires Ubisecure SSO version 6.1.0 or higher.

Example: hide: tupas.alandsbanken.1, tupas.op.1

• show → This property defines the methods that are to be shown. The methods are entered as a comma separated list. Requires Ubisecure SSO version 6.1.0 or higher.

Example: show: tupas.alandsbanken.1, tupas.op.1

Authentication method hiding rules use case example

One application for method hiding rules is in a centralized hub-and-spoke SSO environment, where commercial external authentication services are used with Ubisecure Server acting as an IDP proxy. The Finnish Banking sector authentication service, Tupas, is an example of an external authentication service that charges per transaction. Service credentials stored in the TUPAS configuration settings identify the service that pays for the authentication event.

In order to divide the cost of the authentication transaction, the SSO service may agree that the service which first invokes external authentication pays for the authentication, but other services are free to benefit from the created SSO session and will not be charged for the event.

In order to link this login source event to the authentication method, the following structure is created:

Service A → Contract with bank 1 → credentials are stored in tupas.bank1.1 
Service A → Contract with bank 2 → credentials are stored in tupas.bank2.1 
Service B → Contract with bank 1 → credentials are stored in tupas.bank1.2 
Service B → Contract with bank 2 → credentials are stored in tupas.bank2.2

Each service signs an individual contract with each bank and their service credentials are stored in the Tupas configuration settings of Ubisecure SSO Management.

The application for Service A has all of the banks enabled in the Applications → Allowed Methods tab (tupas.bank1.1, tupas.bank2.1, tupas.bank1.2, tupas.bank2.2) but has the Service B banks hidden (tupas.bank1.2, tupas.bank2.2) using the methodhidingrules file.

The application for Service B has all of the banks enabled in the Applications → Allowed Methods tab (tupas.bank1.1, tupas.bank2.1, tupas.bank1.2, tupas.bank2.2) but has the Service A banks hidden (tupas.bank1.1, tupas.bank2.1) using the methodhidingrules file.

dn: ou=Service A,ou=Services,cn=Ubisecure,dc=com,dc=example
visible: tupas.bank1.1, tupas.bank2.1 
dn: ou= Service B,ou=Services,cn=Ubisecure,dc=com,dc=example
visible: tupas.bank1.2, tupas.bank2.2

The above example ensures that the external bank authentication is invoked using the service credentials of the first service used. Authentication methods that are hidden are still available for use by single sign-on.

If all of the above banks are configured with the same logo and textual description, the end user will see the same menu regardless of the underlying configuration.

Below is an example of a methodimage.index file for the described use case:

tupas.bank1.1  = logo_bank1.gif
tupas.bank1.2 = logo_bank1.gif
tupas.bank2.1  = logo_bank2.gif
tupas.bank2.2 = logo_bank2.gif

The audit logs clearly show the transactions classifiable by external authentication initiating service and can be used, for example, for cross verifying billing statements from the external authentication providers.