Steps on t_azure_oidc_websphere are not entirely correct

[barbj]

Discussed in https://github.com/HCL-TECH-SOFTWARE/HCLSoftware-Documentation-Home/discussions/25

^{Originally posted by **giscus[bot]** February 13, 2024} # connections/v7/admin/secure/t_azure_oidc_websphere 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). This requires that the WebSphereOIDCRP application is installed on each cluster. https://help.hcltechsw.com/connections/v7/admin/secure/t_azure_oidc_websphere.html

[barbj]

Please take a close look at my githb profile and deduce what I do from it. The fact that you are documenting a product that you do not own is causing both your customers and IBM support time and money. The right thing to do is let WebSphere document WebSphere and then you add the customization that you need for your product. This way you inherit changes that WebSphere makes to its documentation, including new recommendations and required procedures.

For instance, start with:

Follow the instructions on https://www.ibm.com/docs/en/was-nd/9.0.5?topic=users-configuring-openid-connect-relying-party . Keep the following in mind:

1. Do not add the RelyingParty class to com.ibm.websphere.security.InvokeTAIbeforeSSO (if that is what you intended)
2. In table 1, use (these) settings.
3. In table 2, set the provider_1.discoveryEndpointUrl to (this)
4. In table 3, set the provider_1.callbackServletContext to (whatever) : [I fixed that property to prepend provider_1; it isn't published yet]
5. Do not set provider_1.mapIdentityToRegistryUser to true

The EAR was installed once, but who cares. Now you can take off to tell them to install the EAR 4 times and give the pics. Tell them to add whatever properties you wanted for provider_1 (like scope and excludedPathFilter) Now tell them to copy all the settings that they made for provider_1, making (these) changes for each one.

Alternatively, you can tell them not to set the properties in the tables, EXCEPT for WAS_DEFAULT. This will keep them from going down the hard path in step 9. Then make a new table in your document that is based on the tables in the current WAS document.

I understand that there are some products that you have steps for are missing end-to-end setup docs, so you have to take action. However, WAS OIDC and SAML do not fit into this category. Sure, we have to leave some things "at will" with the custom properties because the docs are generic to everyone. However, all the steps that are required to get the TAIs operational are in the setup documents. Having you hijack WAS documents misleads both HCL and WAS customers.