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