Updating WebSphere to support single sign-on with Connections for Microsoft Teams
Authentication between the Connections for Microsoft Teams app and the Connections server is handled using single sign-on (SSO). This way, as long as the user's email address in Microsoft Teams matches the email address of the Connections user, the user won't be prompted to log in to Connections.
Before you begin
About this task
Single sign-on is accomplished by setting up a trust relationship between the Connections server and Microsoft Azure using the WebSphere OpenID Connect Relying Party Trust Association Interceptor (OIDC Relying Party TAI). When the Connections app in Microsoft teams connects to the Connections server, it obtains a JSON Web Token (JWT) from Microsoft Azure with the user's identity. This token is presented to the OIDC Relying Party TAI at the Connections server and verified. If valid, the user's identity is used to create tokens that are valid for accessing Connections resources.
- The OIDC Relying Party TAI is setup to intercept only a single endpoint in Connections (/profiles/oidc/session). This endpoint is not used by any other Connections services, so enabling the TAI will not interfere with existing authentication infrastructure.
-
The OIDC Replying Party TAI code is shipped as part of WebSphere Application Server. It is recommended that you are running WebSphere 8.5.5.18 which contains all required fixes. However, if you are running an earlier version of WebSphere, you must install at least version 1.3.0 of the OIDC jar. Find the latest version from https://www.ibm.com/support/pages/node/290565 .
Procedure
- As the WebSphere administrator, in the administrative console, click .
- Click .
- For the interceptor class name, enter com.ibm.ws.security.oidc.client.RelyingParty
-
Add the following properties and values:
Table 1. WebSphere OpenId Connect Relying Party TAI parameters Property Value provider_1.useJwtFromRequest required provider_1.identifier cnx_azure This must be a unique name of an OIDC provider on this instance. Any name is usable as long as it does not conflict with other OIDC provider names.
provider_1.issuerIdentifier https://login.microsoftonline.net/{teams_tenant_id}/v2.0
This must match the "iss" claim from the JWT.
provider_1.jwkEndpointUrl https://login.microsoftonline.com/{teams_tenant_id}/discovery/v2.0/keys
Find this value using the Microsoft OIDC configuration endpoint for your tenant:https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration
provider_1.interceptedPathFilter /profiles/oidc/session provider_1.audiences ALL_AUDIENCES provider_1.setLtpaCookie true provider_1.userIdentifier email This forces the connections server to use the email claim from the JWT as the identifier of the user.
provider_1.useRealm defaultWIMFileBasedRealm -
Add the OpenID Connect Relying Party TAI class to
com.ibm.websphere.security.InvokeTAIbeforeSSO:
-
Disable
com.ibm.websphere.security.disableGetTokenFromMBean
,as when this is enabled, the LptaToken2 coming from /profiles/oidc/session cannot be used to access others' apps in different JVMs.- Click .
- Click Custom Properties.
-
Find the property called
com.ibm.websphere.security.disableGetTokenFromMBean
-
Click and and change the value from true to
false
. - Save the configuration.
-
Configure the trusted realms to include the JWT issuer:
- Click .
- In the User account repository section, click Configure.
- In the Related Items section, click .
- In the External realm name field, enter the issuer name that is used by the JWT.
- Click OK.
-
Add the root signing certificate of the Microsoft Certificate endpoint to the
Default Trust Store:
- Click .
- Click Key stores and certificates.
- Select CellDefaultTrustStore and click Signer certificates.
- Click Retrieve from port.
- For the Host field, enter login.microsoftonline.com.
- For the Port field, enter 443.
- For the Alias field, enter Azure.
- Click Retrieve signer information
- Click OK and save the changes.
- Synchronize all nodes.
- Restart the WebSphere server.