[Remoting] - Re: Concurrent invoke calls
by login4jbr
Oh, thank you very much.
Then I must take care of the concurrency issues on the server side.
I must program the SeverInvocationHandler implementation keeping in mind that multiple threads will execute the invoke() method concurrently.
Is that right?
Do I have to do anything else?
But I think that I don't explained my original question clearly.
I'll try to put it in other words:
I wanted to know if the Client.invoke() method -in the client side- allows various threads to call concurrently.
I've made an experiment with two threads calling Client.invoke() -the same Client instance- and the two threads do their call concurrently and happily.
It's safe and good? is there any problem with this kind of use?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031677#4031677
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031677
19Â years
[Security & JAAS/JBoss] - Generate Token in SSOUtil
by scwhyte
I've been looking in to the source code of JBoss SSO to try to get my head around how it works.
I've noticed that in the SSOUtil.java class, there is a public method called generateToken(AuthResponse). Within this, there is a call to the sso manager instance to generate a token as a string passing in various attribute values of the AuthResponse object. However, the third and final parameter passed is a boolean which is hard coded as being true. i.e. we have:
| token = sso.generateAuthResponse(response.getAssertingParty(),response.getUser().getUserName(),true);
|
This third parameter is used as the 'success' flag, however since this is always passed in as true from the SSOUtil, the method always produces a token string that indicates a valid login.
This generateToken(AuthResponse) method is called by the SSOFederationServer (as part of its doPost):
| AuthResponse authResponse = SSOUtil.getAuthResponse(token);
| String myToken = SSOUtil.generateToken(authResponse);
|
So from what I am reading, the authResponse object created in the first line here, includes whether the authentication was successful or not (determined by making a call to JBossSingleSignOn.parseAuthResponse(String token) - this call checks that the secret in the token is valid using the TrustServer).
However, this status flag in the AuthResponse object (isAuthenticated) is not used within the call to SingleSignOn.generateAuthResponse(...) (which is called from within the SSOUtil.generateToken(..) method), instead it's hard coded to true as stated above.
The effect of this is that if I have two domains in a federation, I was able to capture the token from the first domain, put this in a form, alter the username and even the secret within the token, and then POST it to the federate server in the second domain, and it doesn't throw any errors or send me to the login page, but instead allows me straight through to the resource.
I've been trying this out with the bundled out-of-the-box SSO test application, and I am indeed able to create a token from a previously generated request, alter the secret or user, and when I then post this to the federate URL on the other domain, it lets me in.
Would you be able to clarify if my understanding is incorrect here, or if there's a minor bug slipped through?
Also, one other question, I've noticed that the "secrets" are stored in a collection on the trust server (user->secret mapping), however, I cannot find any way of removing any mappings from this collection, I can only see the "generateSecret" and "validateSecret" actions. Should these mappings be removed when the user logs out? Otherwise, would it not be possible that even after a user has logged out, if someone had intercepted the token, they could log in with the same user->secret in the token?
Hope this makes sense, its difficult to explain without actually being able to 'point' to lines of code :-).
Thanks in advance,
Shaun.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031669#4031669
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031669
19Â years