I'm getting this exception when trying to access a JAX-WS webservice running on the same WAS 7.0 server as the client.
Caused by: javax.xml.ws.WebServiceException: java.io.IOException: Unable to deserialize the Subjects in this Context, cause: the realms do not match
I have a realm set up for user authentication and this call works fine with that realm disabled. Both server and client are running in the same cell.
My current thinking is that my web service is not providing any realm information at all, causing this problem, so I need to do something in my web service to provide a realm - but what? Even google-fu is failing me on this one!
The Realm is set in the LTPA token assigned to the call, and the realms of the client and server needs to match.
I.e. if client authenticates the user and sets and LTPA token with realm="Ldap1:389" then the server needs to have the same realm set. Or it needs to explicitly trust the given realm. This can be set up in WAS admin console, for an explanation of LTPA have a look here:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/csec_ltpa.html
It turned out to be that there needed to be a trust relationship between my local file-based admin realm and the realm I set up for my users to log on with.
WAS seems to do a lot of security gubbins under the covers, but turning on trace output for WSSecurity stuff helps shed light on problems.
Related
I am developing a Node.js web app that uses Keycloak as authentication service. I already have two clients: public client for the web app (app-web) and bearer-only for the API (app-api). On the app-api I use resources, scopes, policies, and permissions to control the access.
To check the permissions, I am using the keycloak.enforcer(...) from the keycloak-connect module (npm keycloak-connect). When I try to check permission, the server always returns 403 Access denied response. But if I change app-api from bearer-only to confidential (keeping the same keycloak.json configuration file), the client works fine and is capable to check permissions.
This problem seems to be because a bearer-only client cannot obtain tokens from the server (keycloak similar question).
My question is: Is this a normal behavior of Keycloak? Why allow the Authorization tab in bearer-only clients if you cannot use the keycloak.enforcer? Am I missing some configuration?
Thanks for your help.
I also stumbled over this bearer-only thing a few days ago. And I also found it confusing that you can enable fine grained authorization, it took me some time to find that out too. Well, a bearer-only client, as the name already states, authenticates clients only by their bearer token.
I posted this question to the Keycloak mailing list too and the answer was:
It is the expected behavior but also a UI issue. You should not have access to that tab when the client is bearer-only.
They even create an issue KEYCLOAK-10808
This is similar to what #Valentin mention.
If you want to read all the thread: Mailing list response
I want to implement login and logout functionality and retrive user details like username and user role using Azure Active Directory.
We are using Docker to deploy Spring cloud microservices project on Azure cloud. Could you please suggest me steps to get user details?
Do we need to secure all microservices edge points using Spring cloud OAuth2 security using JWT or just we can secure one web microservice ? Do I need any permission ,specific user roles to implement this?
You can find Azure's documentation about OAuth 2.0 support for AAD here
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-protocols-oauth-code
I've got an application that's using OAuth 2.0 with a different Authentication Server, and I'm about to see if I can use AAD as the Authentication Server. But, whatever ends up being your Auth Server, the rest of the application should be the same...
The Auth Server handles the log in (typically as a Single-Sign On pattern)
The Auth Server will return a Json Web Token (at some point, depending on the Grant Type being used to retrieve it)
The JWT should be included in each subsequent request to ensure the caller has authorization
From a Spring perspective, you'll need at least a SSO Client (denoted by the #EnableOAuthSSO annotation). If everything in hosted by that process, you'll need that JWT to call subsequent methods. If you have processes hosted in other processes, it's likely you'll want them secured as well. Using the #EnableResourceServer annotation will configure Spring Security to look for the JWT, just not attempt to retrieve one if the request does not have it.
Unless the endpoint is meant to be publicly accessible, you will want to secure it. Of course, I really don't know the context of your application, so this statement is purely an uninformed opinion based on zero knowledge of what you're trying to do with your application. Take it for what it's worth.
EDIT
This has become a little more complex than I originally thought. I have been able to write some code to dynamically retrieve the public key from Microsoft in order to validate the returned JWT.
But, the main issue is the fact the Azure AD supports Open Id Connect when acting as an Identity/Authentication Server. And, at the moment, spring-security-oauth2 doesn't support Open Id Connect.
I was able to make some small changes to the spring code, but I did ask the question to the Spring group and they are actively working on adding support for Open Id Connect. They hope to have a release two months (ish?).
For the short term, the oauth2 support doesn't support Open Id Connect. Given this is the protocol used by AAD, the current version of oauth2 won't work with AAD. That said, I will be happy to wait for the official support which shouldn't be too long.
I have been working on IBM Maximo Anywhere apps such as Work Approval and Work Execution for sometime now have few queries regarding the login mechanism used by these apps. To be specific as per my understanding anyone having access to maximo on that particular environment can login into the anywhere apps - is that a correct statement? and if yes then how does it work in a disconnected state? If for any reason maximo is down will it mean that the app will not be able to authenticate a user and hence unable to login as well? And alongwith that is there any other kind of authentication done for example LDAP etc? Are there any different kinds of login failure messages that are displayed depending on why the app isnt able to let the user login? or is it a common one saying "Login Failed"
The first time the user ever logs into the application, they do have to have a connection to the Maximo server to authenticate. We also validate that the user is authorized to use this particular mobile app. We have a security group for each mobile app that the user must be a member of. After the authentication and authorization finishes, we download, store, and sign the locally stored data with the username/password combination, so that on subsequent login attempts, if the server is down, we can fail over to the locally stored data. This also guarantees that the locally stored data is protected.
We support all of the types of authentication configuration that base Maximo supports.
More information here:
http://www-01.ibm.com/support/knowledgecenter/SSPJLC_7.5.0/com.ibm.si.mpl.doc_7.5.0/security/c_authentication.html
we have deployed a OpenAM V10 cluster with two nodes and sometimes and several SPs configured. When a user logs into the system, the systems validates its credentials and starts the user session but sometimes it seems to "cross" the session with one from another user whom is already logged into the system. After that, when the user tries to access any of the registered SPs an error is shown and it's forced to be logged again. So, in fact, it's not really a security problem but it's not cool at all.
We really don't know if the problem is in OpenAM or in the load-balancer.
Any idea is welcome.
OpenAM does not use HTTP session but it's own session id which is cryptograhically secure, so it's very unlikely there is a SSO session ID clash.
It's not clear what "cross the session" really means ... a session in you app? Then it's an application issue, not an OpenAM issue.
It will never be an LB issue.
I created an iWidget for IBM Connections, which has to retrieve data from our external web application through the provided proxy. However, said application requires the user to be authenticated before providing an answer.
Is there any general recommendation on how to solve this? I'm aware that I can get the current user from the iScope of the widget, but just forwarding this information to our application is not secure - since everyone could just create such a request, pretending to be any user. I also know that the proxy can be configured to forward ltpa credentials, but I dont know how to validate such a token - maybe IBM provides a library for this task, that I'm just not aware of?