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.
Make sure you've completed Enabling Connections to use the app registry service.
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.
Important: Like the chat integration for Teams, this SSO setup does require that the email address for the user's Teams identity matches the email address in Connections.
Note:
- 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 .
-
As the WebSphere administrator, in the administrative console, click Security > Global security > Web and SIP security > Trust association .
-
Click Interceptors > New to add an interceptor.
-
For the interceptor class name, enter com.ibm.ws.security.oidc.client.RelyingParty
-
Add the following properties and values:
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/{teams_tenant_id}/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:
-
Click Security > Global security and then click Custom properties
-
Check the list for
com.ibm.websphere.security.InvokeTAIbeforeSSO
. At the end of the existing value, add",com.ibm.ws.security.oidc.client.RelyingParty"
.Note: This begins with a comma.
-
Click OK.
-
-
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 Security > Global security.
-
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 Security > Global security .
-
In the User account repository section, click Configure.
-
In the Related Items section, click Trusted authentication realms - inbound > Add External Realm.
-
In the External realm name field, enter the issuer name that is used by the JWT (same as provider_1.issuerIdentifier above).
-
Click OK.
-
-
Add the root signing certificate of the Microsoft Certificate endpoint to the Default Trust Store:
-
Click Security > SSL certificate and key management.
-
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.