Integrate UBIK in an SSO Environment
Single Sign-On (SSO) allows an end-user to interact with multiple services without logging in more than once.
This page shows how to integrate UBIK® into such an SSO environment.
Instructions
Important information
SSO has additional benefits, other than "just" reusing a central account and session. It also makes sure that no application other than the identity provider (and the browser) ever gets to see the user's credentials, and two-factor-authentication (2FA) can be enforced.
Some organizations do this by restricting every HTTPS interaction in their network, making sure that all requests carry a session cookie known by the identity provider, or otherwise redirecting the request to the identity provider (via an application gateway, reverse proxy or load balancer), so the user can login right away with their browser.
This works out well for all web applications running in the user's browser. However, many applications do not run within the user's browser, like for example demon services, or native mobile applications. But such applications often still use HTTPS to interact with other services or even their own servers, just not using a browser. This is also true for UBIK®.
So how can such browser-less interactions be secured with SSO? UBIK® can be configured to require a valid SSO login via the user's web browser to create surrogate session tokens for the browser-less back channels. This renders interception by an application gateway not only useless, but also obstructive.
In other words, it is mandatory to exclude the UBIK® web service URLs from 2FA rules on the application gateway, so UBIK® can implement SSO securely without being a web application.
We've had the situation multiple times that customers or partners are worried that this is a breach of their cyber security protocols. This is not the case: We have ensured that UBIK® can be configured to prevent ANY session that is not secured via the identity provider! The responsibility for securing the back channel has to be with UBIK® though, otherwise it cannot work technically, because UBIK® is not a web application where all communication runs via the browser.
We understand this is a complex topic. Please don't hesitate to approach our support if there are further questions!
Login
As explained in the Single Sign-On article, we want the mobile application to receive a token of authenticity from an authority the user has provided their credentials to. Next, the mobile application should ask the USAM web service to accept this token as credentials and establish a UBIK® session. Of course, the USAM web service must verify whether the token is valid. If so, an internal UBIK® login object is created for the user, if it doesn't exist yet. This can be customized in order to add further information to the login object (like a name, group relations or other arbitrary information), or to restrict which users may log in, now that their identity is verified.
To implement this, the following steps must be done:
- UBIK® must be registered as a client application (or "service provider" in SAML) at the customer's authority or identity provider (IdP).
- The service engineer must provide a callback URL at which we want to receive the result. In case of OIDC, this is the app's deep link URL "com.augmensys.ubik://SSO". For SAML, an intermediate server (assertion consumer service, ACS) is required to relay the token for the app - we provide the UBIK® auth mediator server for this.
- In return, the customer must provide a client ID and client secret for us to configure.
- In case of OIDC, the customer can decide which scopes/claims should be delivered with the token and whether they want to use the ID token or the access token for authentication.
- In the UBIK® client profile, the SSO relevant settings must be adjusted (enabling SSO, specifying the protocol, the IdP URL, client ID, client secret, scopes and whether to use the access token).
- On the server side, make sure that an SSO Processor is configured able to process the responses from the IdP. Also, the processor can be customized for managing the login in greater detail and according to the project's requirements.
Interfacing with SSO
When a UBIK® object is synchronized between client and server, the UBIK® customizing can interact with external systems. There, we might require authentication, and we need the user to provide a respective token so we can act on their behalf. In order to do so, we have to clarify the following details:
- For which types of objects (meta classes) do I need to interact with external systems, requiring SSO authentication?
- For which synchronization operations (e.g., update, commit, create, etc.) do I need authentication?
- Which SSO client configurations (identity provider base URL, scopes, etc. - see "login") are used in this case?
For each resulting combination we have to create an External Auth Config object and give it to the client in the infrastructure list.
Further, we have to make sure the authentication tokens can be transported to the server. Therefore, add the External Entity Classification to all meta classes of objects that need external authentication.
With this, the UBIK® session in the web service's UBIK® Environment is tagged with the SSO token, and the customizing code can use it to interact with 3rd party systems.
Studio
Login
- Install the Auth Processor plugin (SAMLProcessor or OIDCProcessor plugin) in your web service's injection folder
- Customize your UBIK Context, overriding the method "GetSSOProcessor" so it returns an instance of the authentication processor
Applying an SSO Processor
In the case of a periodic rolling of the signing key, use the DynamicOIDCProcessor which fetches the JWKS automatically via the base URL of the chosen OIDC Provider:
{
if (this.Name == "MyContextName")
{
string authorityBaseUrl = "...";
return new UBIK.SSO.OIDCProcessor.DynamicOIDCProcessorExt(Environment, token, authorityBaseUrl);
}
return base.GetSSOProcessor(token);
}
Instead of "..." you will need to insert the correct URL from your OIDC Provider where the JWKS should originate from.
If the JWKS does not roll periodically:
{
if (this.Name == "MyContextName")
{
string jwks = "...";
return new UBIK.SSO.OIDCProcessor.OIDCProcessorExt(Environment, token, jwks);
}
return base.GetSSOProcessor(token);
}
You will need to insert the correct jwks from your OIDC Provider instead of "...".
public override UBIK.Kernel.SSO.ISSOProcessor GetSSOProcessor(System.String token)
{
if (this.Name == "MyContextName")
{
byte[] certificate= null; // load from file
return new UBIK.SSO.SAMLProcessor.SAMLProcessorExt(Environment, token, certificate);
}
return base.GetSSOProcessor(token);
}
You will need to load the correct certificate from your SAML Identity Provider instead of null. It's recommended to save the certificate on the server and load it from file storage. The certificate must be the one the IdP uses to sign its SAML responses with.
Customizing the SSO processor
There are several use-cases where we need to customize the SSO processor. We can define what should be done when a login object is required or found, and we can use the information delivered with the SSO token in the form of assertions or claims. In any case, we must override the SSO processor implementation, e.g.:
{
// Example for a claim type identifier used to get a value from the Assertions() dictionary.
public const string KEY_MAIL = @"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress";
public MyOIDCProcessor(UBIKEnvironment environment, string token, string authorityBaseUrl) : base(environment, token, authorityBaseUrl)
{ }
protected override Login CreateLogin(string loginName, string domain, UBIK.Service.DTO.V220.OSTypes osType)
{
// In this example, we use the default login creation, but add the email address as the human-readable login name.
// However, we could also use a special MetaClass for creating the login instance or do anything else we require.
Login login = base.CreateLogin(loginName, domain, osType);
// The Assertions() method yields a Dictionary<string, object>, where the values usually are strings, too.
// The keys correspond to the claim type identifiers.
if (Assertions().ContainsKey(KEY_MAIL) && !string.IsNullOrEmpty(Assertions()[KEY_MAIL] as string))
{
login.Name = Assertions()[KEY_MAIL] as string;
UBIKKernel.LogCustomizing(MethodBase.GetCurrentMethod(),
$"Login name for {login.ID} was set to {login.Name} -> Key: {KEY_MAIL}");
}
return login;
}
public override string GetLoginID()
{
// Here, we could influence the login ID used in UBIK, if we have a good mapping.
return base.GetLoginID();
}
public override Login GetLogin(UBIK.Service.DTO.V220.OSTypes osType)
{
Login login = base.GetLogin(osType);
if (login != null)
{
// Here, we could update groups assignment or other account information.
// If the login object is modified here, please remember to call the login.Save() method before returning!
}
return login;
}
public override bool IsValid()
{
// Here, we could only accept trusted accounts, for example.
return base.IsValid();
}
}
Interfacing
- Add External Auth Config objects to the client's infrastructure
- Add the External Entity Classification to all affected meta class scopes
An external auth config object specifies for which meta class and sync action (e.g., when uploading instruction documents), which SSO configuration should be used. The result of a correct configuration will be that the client sends an SSO token to the server when performing the sync action for an instance of the meta class. On the server side, you can use that token to interact with the external system. This only works if there is a scope with the external entity classification for that meta class, because it provides the means to transport the token.
Here's how the SSO token can be retrieved by the server side customizing (only when executed by the web service that received the content though, for security reasons):
{
UBIKKernel.LogDebugOutput(MethodBase.GetCurrentMethod(), 1234, "Getting OIDC Token", this);
UBIK.Kernel.Classification.SSO.SSOCacheKey key = new UBIK.Kernel.Classification.SSO.SSOCacheKey(op, c.ClassID);
if (session.Tags.TryRetrieveTag(key, out object tag))
{
string oidcToken = tag as string;
return oidcToken;
}
else
{
UBIKKernel.LogDebugOutput(MethodBase.GetCurrentMethod(), 1234, "No OIDC token found in session " + session.ID + " for ioOperation " + op + " and class ID " + c.ClassID, this);
}
return null;
}
Client
OIDC
- Set up an identity provider if necessary
- Assemble a client configuration JSON string, .e.g. for Entra:
'ClientID' : '{clientid}',
'ClientSecret' : null,
'RedirectURL' : 'com.augmensys.ubik://SSO',
'Scope' : 'openid',
'UseAccessToken' : 'false'}
- Integrate client configuration in profile:
<EnableSSO>true</EnableSSO>
<SSOConfiguration>
...
</SSOConfiguration>
<SSOProtocol>OIDC</SSOProtocol>
</InternalSSOSettings>
 | Entra requires a client secret for web applications (to be configured both in Entra as well as in the client profile's OIDC settings described above). For native/mobile applications, the client secret must be null though! |
SAML
- Set up an identity provider if necessary
- Set up an SSO mediator backend server to relay SSO responses to the client
To set up an Authentication Mediator Server first go to http://release.augmensys.com/ and download the provided Zip File. After you downloaded the Zip create a new IIS applicatio (https://docs.microsoft.com/en-us/iis/configuration/system.applicationhost/sites/site/application/). Open the just created app in your file explorer, unpack the downloaded ZIP file and copy all files of that ZIP into the app-folder. If IIS prohibites you to copy files you need to first stop the server. After successfully copying the Files you need to Restart/Start the IIS server again. Now you have set up the Authentication-Backend and it is ready to use.
- Assemble a client configuration JSON string, .e.g.:
- Integrate client configuration in profile:
<EnableSSO>true</EnableSSO>
<SSOConfiguration>
...
</SSOConfiguration>
<SSOProtocol>SAML</SSOProtocol>
</InternalSSOSettings>
