Original Message:
Sent: Thu April 27, 2023 04:30 AM
From: Petre Petreski
Subject: Websphere and Azure AD
Hi Barbara,
I would like to add one more clarification on the topic. I can do the redirection in my web.xml file in my application with filter-mapping and url-pattern but it is being bypassed now by the OIDC TAI .. I saw that in WAS_HOMEconfig\cells\petrespeNode01Cell\applications\WebSphereOIDCRP.ear.ear\deployments\WebSphereOIDCRP.ear\com.ibm.ws.security.oidc.servlet.war\WEB-INF in the web.xml file the following configuration:
<security-constraint>
<web-resource-collection>
<web-resource-name>General</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>Admin</role-name>
</auth-constraint>
</security-constraint>
<security-role id="SecurityRole_1">
<description>Users with this role are allowed</description>
<role-name>Admin</role-name>
</security-role>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>
</web-app>
I tried to remove /* from the provider_1.interceptedPathFilter but when I try to open https://localhost it prompts fro basic authentication (needs usr/pass)
How I can use my web.xml file so I can do the filtering and redirection ..?
------------------------------
Petre Petreski
Original Message:
Sent: Wed April 26, 2023 02:28 PM
From: Petre Petreski
Subject: Websphere and Azure AD
Hi Barbara,
OK it's clear if I want to log out from WebSphere & Azure I need to upgrade the WAS to 8.5.5.23 and configure RP-Initiated logout.
My question about OIDC TAI was:
I have a logon.jsp page that is excluded from the pathFilter
provider_1.excludedPathFilter
|
/logon.jsp
|
and I want when I try to open https://localhost/ if I am not logged in in Azure to be redirected to https://localhost/logon.jsp, so the user will have a form with "Sign in" button there, and when they click on it will be redirected to microsoft login page..
Or it is not possible, the whole link https://localhost/logon.jsp should be provided to the user,, and this is the only way to access this form.
------------------------------
Petre Petreski
Original Message:
Sent: Tue April 25, 2023 07:13 PM
From: Barbara Jensen
Subject: Websphere and Azure AD
Hi Petre,
Do you mean that, when you perform a form logout 1) your LTPA cookie is persisting after logout, or 2) you can access your protected resource again without creds after logout?
If your logins are protected using OIDC, your LTPA cookie should be deleted upon form logout, but prior to 8.5.5.23, the OIDC session cookie is not. The result of this behavior is that, when you navigate to your protected resource again, the OIDC TAI thinks that the user is still logged in and lets the request pass without redirecting to the OP. This is happening because core security is not redirecting the form logout request to the configured TAIs, thus not giving the OIDC TAI the opportunity to delete its session cookie.
If your LTPA cookie is not being deleted upon a form logout, that is not expected and is a problem.
If you upgrade to 8.5.5.23 and get the OIDC TAI to delete its session cookie, unless you also configure RP-Initiated logout, it is likely that you will still be able to navigate to the protected resource without creds. This is because your OP is probably also tracking the logged in user in the browser. For instance, this is very common with Google and Facebook (although FB is not OIDC, but you get the idea). The user is logs out of WebSphere. Upon re-login, OIDC sends a login request to the OP, then the OP sends a response without requiring creds (instead of WebSphere not requiring creds; a subtle difference that produces the same external result).
> I have a question about the OIDC provider.
Do you mean a question about the OIDC TAI?
> check if there is no active session (user is not logged in)
Do you mean if there is a user logged in to WebSphere?
I don't think that you could do that. Because you might be using OIDC and turn of LTPA. You might have an LTPA cookie, but the protected resource is not the one for which the cookie was written. This is a complicated matter.
==> In summary, if you have a resource that is protected by OIDC, and that resource uses form logout, if you want the logout to work correctly, you need to use 8.5.5.23 or later. I don't see any other way around it. There are no interim fixes for PH48145 for any fix pack at this time.
------------------------------
Barbara Jensen
Original Message:
Sent: Mon April 24, 2023 05:08 AM
From: Petre Petreski
Subject: Websphere and Azure AD
Hi Barbara,
thank you very much for the thorough explanation. For the logout function I had in mind in the current 8.5.5.20 version that it does not work well (LTPA token remains active even after ibm_security_logout?logoutExitPage=logon.jsp), but it is good to know how it can be fixed with the OIDC session cookie. Is there any fix pack for 8.5.5.20 that fixes this?
OK above is regarding the LTPA cookie if you have some suggestion will be grateful.
I have a question about the OIDC provider. Is it possible somehow when I Open the root url (ex: https://localhost/) to check if there is no active session (user is not logged in) to redirect me to let say https://localhost/logon.jsp ? Is there any custom properties for that, or any suggestion how we can do it? Before we switch to OIDC we were using filter classes descripted in web.xml but now since it is interceptop this web.xml is skipped, I beleive..
Thank you!
------------------------------
Petre Petreski
Original Message:
Sent: Tue April 11, 2023 09:35 AM
From: Barbara Jensen
Subject: Websphere and Azure AD
Hi Petre,
Oh, so...logout. Your problem with logout is not with the LTPA cookie, but with the OIDC session cookie. There is a problem with ibm_security_logout not calling the TAI logout methods (APAR PH48145). PH48145 is included in 8.5.5.23 and 9.0.5.14; since the APAR is part of core security and not OIDC, it is not included in the OIDC 1.4.0 ifix. To fix this issue, you must install one of those fix packs or later.
And then after you get PH48145 fixed, since you are using Azure AD, when the user clicks login, they'll still be able to access your application without having to provide credentials. Why? Although the user is logged out of WebSphere, they are not logged out of Azure. When a new request is sent to WebSphere, it detects that the user is not logged in. The TAI sends a request to Azure and Azure responds with access and id_token without requiring credentials from the user.
You can configure the OIDC TAI to logout of Azure when the user logs out of WebSphere. This is called RP-Initiated logout. However, you shouldn't take making the decision to logout of Azure lightly. Doing this circumvents some of the usefulness of SSO. You ordinarily want to do this only with sensitive apps. For example, banking apps on the internet. If you are on an intranet and have multiple applications that use the same Azure AD, if you logout of your application and have it perform RP-Initiated logout, the user is logged out of all applications (at least in that browser). That could be a negative user experience.
If you want to configure the TAI for RP-Initiated logout, see Configuring the OIDC TAI to perform RP-initiated logout. RP-Initiated logout was implemented in APAR PH48083 and is also included in 8.5.5.23 and 9.0.5.14.
Here is something that is not noted in either PH48083 or the RP-Initiated logout instructions., but it is in the PH48145 closing text as instructions to TAI developers:
=======================
logout_exit_page is set to a normalized value of the logoutExitPage parameter if core security deems the value for logoutExitPage valid, otherwise it is not set. Note that the value of logout_exit_page parameter might be a relative reference. If your custom TAI uses the value for logout_exit_page and requires an absolute URI, your TAI must take this into account.
Core security only allows a URI to the current JVM for the logoutExitPage parameter for the ibm_security_logout method when the com.ibm.websphere.security.allowAnyLogoutExitPageHost security custom property is set to false (the default).
=======================
Your logoutExitPage is a relative reference. The OIDC TAI uses the value for the logoutExitPage as-is. This will not fly with Azure AD, so you will need to set the provider_1.endSessionRedirectUrl and not provider_1.endSessionUseLogoutExitPage=true so that Azure can address the URL.
EDIT:
To the Configuring the OIDC TAI to perform RP-initiated logout topic in IBMDOCS, the following text will be added below the example in step 4:
================================
When provider_<id>.endSessionUseLogoutExitPage=true
, the OIDC TAI uses the value for the logoutExitPage
as-is. If it is a relative value, a relative value is sent in the logout request to the OP.
A new optional step 5 will be added:
================================
Optional: If any of your applications use form logout and the value for the provider_<id>.endSessionRedirectUrl
property is a URL that does not address the current JVM, make sure the following core security custom property is set to true
:
com.ibm.websphere.security.allowAnyLogoutExitPageHost
To find or set the com.ibm.websphere.security.allowAnyLogoutExitPageHost
property, navigate to Security > Global security > Custom properties
in the administrative console.
These updates won't show up until the next fix pack.
------------------------------
Barbara Jensen
Original Message:
Sent: Tue April 11, 2023 07:12 AM
From: Petre Petreski
Subject: Websphere and Azure AD
Hi Barbara,
Yes, I mean the LtpaToken2. I am asking you, since currently it does not behave as I expect. For example even the user signs out (ibm_security_logout?logoutExitPage=logon.jsp, or request.logout()), the LtpaToekn2 remains active, it is not destroyed in the server. For example if I take the LtpaToken2 value and log out after that, I can use the LtpaToken2 value as a cookie and can construct and do valid http request (even I am logged out). I do not know if it is a bug.. (WebSphere 8.5.5.20). That's why I thought that now when we are switching to Azure AD session tracking will be done by it. For sure for me is better to keep the current configuration and will appreciate if you can suggest how the LtpaToken2 cookie can be destroyed in the server.
Thank you!
------------------------------
Petre Petreski
Original Message:
Sent: Mon April 10, 2023 12:53 PM
From: Barbara Jensen
Subject: Websphere and Azure AD
Hi Petre,
Do you mean the LtpaToken2 browser cookie? The LtpaToken2 browser cookie tracks the user that is logged into WebSphere; it doesn't have anything to do with a specific registry that WebSphere can use. If you want your WebSphere environment to behave as it did before, I suggest that you not change your use of the LtpaToken2 browser cookie.
------------------------------
Barbara Jensen
Original Message:
Sent: Mon April 10, 2023 12:21 AM
From: Petre Petreski
Subject: Websphere and Azure AD
Hello Barbara,
Thank you very much, following your instructions I successfully retrieved claims. Now I need another assistance from your side. Currently, we are using a federated LDAP repository for authentication, that is configured in WebSphere. As I mentioned, we preparing our environment to switch from LDAP to Microsoft Azure AD. For that purpose we configured OIDC provider in WAS. My question is about an LTPA token. Should we (if it is possible) remove its configuration from WAS or we will continue use it, despite of switching to AZure AD?
Also should we change the current WebSecurityConfig ? Can you provide some similar example so we can follow it?
@Bean
public PreAuthenticatedAuthenticationProvider preAuthenticatedAuthenticationProvider() {
final PreAuthenticatedAuthenticationProvider provider =
new PreAuthenticatedAuthenticationProvider();
provider.setPreAuthenticatedUserDetailsService(customUserDetailsService);
return provider;
}
@Bean
public AccessDeniedHandler accessDeniedHandler() {
return new CustomAccessDeniedExceptionHandler();
}
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authenticationProvider(preAuthenticatedAuthenticationProvider());
if (usesLoginForm) {
http.jee().and().csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
} else {
http.cors().and().csrf().disable();
http.authorizeRequests().antMatchers("/").permitAll();
}
http.sessionManagement()
.sessionCreationPolicy(SessionCreationPolicy.NEVER).
sessionFixation().none();
http.exceptionHandling().accessDeniedHandler(accessDeniedHandler());
}
Thank you in advance!
------------------------------
Petre Petreski
Original Message:
Sent: Tue April 04, 2023 12:03 PM
From: Barbara Jensen
Subject: Websphere and Azure AD
Hi Petre,
If you have the OIDC TAI configured in WebSphere Application Server and want to retrieve claims from an id token after login, you can use the com.ibm.websphere.security.oidc.util.OidcClientHelper class. There is an example at the top of the page to show you how to get the claims from an id token as a Map:
String idTokenJwt = OidcClientHelper.getIdTokenFromSubject(); //get the claims string String idTokenClaims = OidcClientHelper.getJwtClaimsAsString(idtokenJwt); //-or- get the claims map Map<String,Object> claimsMap = OidcClientHelper.getJwtClaimsAsMap(idtokenJwt);
------------------------------
Barbara Jensen
Original Message:
Sent: Tue April 04, 2023 07:34 AM
From: Petre Petreski
Subject: Websphere and Azure AD
Hello Barbara,
Thank you for the detailed explanation of how-to procedure for configuring OIDC provider.
I configured it as you described and when I access the application it redirects me to https://login.microsoftonline.com/ landing page and I enter my credentials and I get my web application.
I use spring boot 1.5.8.RELEASE with Spring Security 4.2.3.RELEASE.
I need some example how I can configure my WebSecurityConfig to use the configured provider in the WAS, so I can get the claims from the token. If you need some part of the my code let me know.
Thank you in advance!
------------------------------
Petre Petreski
Original Message:
Sent: Thu March 30, 2023 10:50 AM
From: Barbara Jensen
Subject: Websphere and Azure AD
Hi Sudheesh,
You're so very welcome. I'm glad that I could help.
There is one observation , after redirecting back from Azure AD the url to be accessed is asking my console username and pwd which I configured during the installation of IBM WAS. when I give the right credentials the URL is properly accessible . Is it an expected behaviour after redirect?
No, this is not expected behavior.
I suspect that you either have a realm or username problem.
First check for a realm problem. See: This realm is not the current realm, nor the admin realm, nor a trusted realm
If the realm name isn't the error, the next thing to check is the user name.
Is the user name correct in this trace statement?
If it is not, then you need to check the id_token that is received from the OP to find the claim that the username is in. The default is the sub claim.
When you find the right claim, you set it on the provider_1.userIdentifier property (and probably provider_1.uniqueUserIdentifer too).
To find the id_token claims, search the trace for "id token". You'll find a trace statement that looks like this:
------------------------------
Barbara Jensen
Original Message:
Sent: Thu March 30, 2023 04:18 AM
From: sudheesh krishna
Subject: Websphere and Azure AD
Dear Barbara Jensen,
Its working for me now ,I am now able to protect my /snoop url :)
Thank you very much for all your support, really appreciate your patience in replying to my all questions.
There is one observation , after redirecting back from Azure AD the url to be accessed is asking my console username and pwd which I configured during the installation of IBM WAS. when I give the right credentials the URL is properly accessible . Is it an expected behaviour after redirect? if we want to remove this extra login screen what can be done?.PFA screenshot
Thanks,
Sudheesh
------------------------------
sudheesh krishna
Original Message:
Sent: Mon March 27, 2023 12:33 PM
From: Barbara Jensen
Subject: Websphere and Azure AD
Hi Sudheesh,
I apologize, you should try 9443 for your HelloWorld app, not 9043. You received the SRVE0255E message because the OIDC URL is not defined on the admin port.
Its not a good idea to protect the admin console with OIDC unless you are fully aware of the ramifications, can install 9.0.5.14, and are an expert at OIDC and AD configuration.
I've sent the rest of my reply in a private message.
------------------------------
Barbara Jensen
Original Message:
Sent: Sat March 25, 2023 03:40 AM
From: sudheesh krishna
Subject: Websphere and Azure AD
Dear Barbara Jensen,
First & foremost thank you very much for all your replies for my all questions .I really appreciate your patience and willingness to help others:)
Finally something is working for me even though its not up to the mark.
I changed the intercepting URL of the TAI filter to /.* , rest remain the same, and restarted the server and now the URL
"https://localhost:9043/ibm/console" being protected and taking me to Microsoft login Page. However On redirect I am getting some exception. I have attached the complete log trace, Redirect URL I configured and err screenshot herewith.
However my application is running under url "localhost:9080/HellowWorld is not intercepted here
When I installed ibm websphere i configured "Admin console secure port as 9043 and Https transport port as 9080 i.e default values. Please find port config screenshot.
My questions are now is
- Why its not intercepting for URL "localhost:9080/HellowWorld" I remember you said me to call application with same port 9043 instead of 9080 i.e "localhost:9043/HellowWorld" but this notworking for me.
- Why after redirect from Microsoft I am getting below error, Now I am not able to login to console any more due to this exception but its redirecting me to MS login page"
SRVE0255E: A WebGroup/Virtual Host to handle /oidcclient/abc has not been defined.
"
Thanks,
Sudheesh
------------------------------
sudheesh krishna
Original Message:
Sent: Thu March 23, 2023 06:27 PM
From: Barbara Jensen
Subject: Websphere and Azure AD
Hi Sudheesh, Here is a version of the troubleshooting steps that are specific to OIDC so you don't have to translate from SAML: https://www.ibm.com/support/pages/node/540247/#noIntercept . Sorry that I didn't realize that I already had those steps in the OIDC document.
------------------------------
Barbara Jensen
Original Message:
Sent: Thu March 23, 2023 09:27 AM
From: Barbara Jensen
Subject: Websphere and Azure AD
Hi Sudheesh, as I said in my previous post, running the python script is not essential for making the scenario work. All you need to do is get the OIDC ear, WebSphereOIDCRP.ear, installed. You can install the app_server_root/installableApps/WebSphereOIDCRP.ear file using the admin console:
- In the admin console, navigate to Applications > Application Types > WebSphere enterprise applications
- Check your application list for WebSphereOIDCRP.ear. If you find it, you're done. Don't worry about installing the ear or running the python file ever again.
- Otherwise, continue.
- Click Install
- Click Browse
- Enter the path to (WAS_HOME)/installableApps. For example, c:\was90\WebSphere\AppServer\installableApps
- Select WebSphereOIDCRP.ear, then click Open
- Click Next through the subsequent panels, taking all defaults, then click Finish
- Click Save
- Restart the application server
Once you have the ear installed and the TAI configured, before you attempt to run a test, you'll need to set the OIDC trace specification to debug problems (as show in the link that I provided previously):
*=info:com.ibm.ws.security.oidc.*=all:com.ibm.ws.security.openidconnect.*=all:com.ibm.ws.security.openid20.*=all:com.ibm.ws.security.web.*=all
I do not see that this trace spec is set in your file. After you set this trace spec, you can use the debug page that I gave you to help debug problems.
Next: I suggest that you backtrack and use the snoop application to debug your TAI configuration instead of your own app. After you get the TAI working, you can then modify the filter for your target application. Why do I suggest this? Because it separates any TAI problems that you might have from application problems. Once you know that the TAI config is working, if you encounter an error when you switch over to protect your app, the problem is most likely the app (or filter config) and not the TAI. This is why all the examples use snoop.
To do this, change your provider_1.interceptedPathFilter to /snoop, then use the URL https://(host:sslport)/snoop in the browser.
snoop should already be on your server. It is in defaultApplication.
------------------------------
Barbara Jensen
Original Message:
Sent: Wed March 22, 2023 08:13 AM
From: sudheesh krishna
Subject: Websphere and Azure AD
@Barbara Jensen
Hi , I tried to execute that python script to install OIDC, however this time too no luck :(
I have attached the log of my application and there is some exception for which I do not have any clue.
Please find the attached log here with, I am also checking for solutions for the same.
------------------------------
sudheesh krishna
Original Message:
Sent: Thu March 16, 2023 11:25 AM
From: Barbara Jensen
Subject: Websphere and Azure AD
Hi Sudheesh,
The installOIDCRP.py script installs WebSphereOIDCRP.ear that is required by the TAI. It does not update the TAI itself. Running this script is equivalent to doing step #3 in the example. If you performed step 3 successfully, then you do not have to worry about any errors that you received from installOIDCRP.py.
- I suggest that you access your app from https://localhost:9043/HelloWorldFirst/ instead of http://localhost:9080/HelloWorldFirst/ if possible. This will prevent further configuration.
- Set up the OIDC trace on the application server as specified in this document: https://www.ibm.com/support/pages/mustgather-web-single-sign-problems-websphere-application-server .
- You do not need to do the browser trace.
- After you restart your server, run your test one time, then bring up the (profileRoot)/logs/(serverName)/trace.log file in an editor.
- Now go here: https://www.ibm.com/support/pages/node/277989/#noIntercept
- Yes, this is a SAML troubleshooting guide, but this section mostly applies to all TAIs.
- On step 3, check for com.ibm.ws.security.oidc.client.RelyingParty instead of com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor
- On step 4, again, the RelyingParty class instead of ACSTrustAssociationInterceptor
- On step 5, you still search for isTargetInterceptor. The trace line is similar:
RelyingParty > OIDC: isTargetInterceptor(https://localhost:9443/snoop) Entry
checking for false too:
RelyingParty < ==> OIDC: isTargetInterceptor returns [false] Exit
Go through this debug procedure and see if it helps you make progress.