I have a web application on Jboss 4.2.2 and in its login sequence I have added a custom login module. In the getIdentity() of this module, for some reason I need to change it to be other than the username entered in the login form.
On any jsp page, I can get this identity with no problem by request.getRemoteUser(). However, when I tried to retrieve this value in an EJB using ctx.getCallerPrincipal().getName() , it returns the username entered in the login form. So I would like to ask in what ways can I get the identity I expected.
Thanks in advance.
Should be a bug on jboss
https://issues.jboss.org/browse/EJBTHREE-1756?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
Related
Trying to retrofit an old webforms application.
Got my configuration working so that it's prompting for login and successfully redirecting back to the application. The folks that manage the IP can see the response is generated.
However in the callback to my application the User is null. I'm told if it's configured correctly it should be populated.
We have a custom IHttpModule and that is where I can see getting hit with the call to /Saml2/Acs with the User not populated. I think this may be expected as the handler for that is supposed to populate the User, I think? However the following call (the returnUrl configured in sustainsys.Saml2) still has no User and I don't see any sort of error or anything.
Anyone with experience have an idea how to debug this?
The call to /Saml2/Acs should be taken care of by the Sustainsys.Saml2.HttpModule. It will process the response and then call the SessionAuthenticationModule to set a cookie that preservers the User across calls.
To get some more information about what's happening in the library, you can assign an implementation of ILoggerAdapter to Sustainsys.Saml2.Configuration.Options.FromConfiguration.SPOPtions.Logger to get some logging output from the library.
My issue turned out to be that I had another authentication module loaded before SessionAuthenticationModule and Saml2AuthenticationModule in the web config.
The comment in the example was
Add these modules below any existing. The SessionAuthenticatioModule
must be loaded before the Saml2AuthenticationModule
However in my case with I had another authentication module involved that needed to go last.
I'm working with tomcat 7, Java EE6. I'm using form-base authentication and all working fine. But I would like to use the parameters of the form j_security_check, these are the j_username and j_password, in order to use them to initialize a User object.
I haven't find information regarding it, so what I´m doing is to make the user to register two times, once to enter the protected area with form-base authentication (tomcat 7) and a second time to get the same parameters (j_username and j_password ) and initializing the user object, but I'm wondering if this second step could be avoided. Thank you!!!
You can use javax.servlet.http.HttpServletRequest.getRemoteUser() to recover the username that was used to authenticate.
You can then use this to lookup the password (hopefully one-way hashed) in whatever user registry it is that you have configured in Tomcat.
I'm using the Grails Spring Security Core plugin and now adding in Facebook authentication via the Facebook Authentication for Spring Security Core plugin. I'm able to authenticate with Facebook, however it's always redirecting back to an incorrect URL. I want to redirect to localhost:8080/rar/user/home, however after login I'm redirected to localhost:8080/rar/#_=_. When logging in through a standard login form I am redirected properly to localhost:8080/rar/user/home.
My FB app settings has http://localhost:8080/rar/ for the Site URL. I'm using these plugins:
compile ':spring-security-core:2.0-RC2'
compile ":spring-security-ui:1.0-RC1"
compile ":spring-security-facebook:0.15.2-CORE2"
And have these config settings:
grails.plugin.springsecurity.successHandler.defaultTargetUrl = '/user/home'
grails.plugin.springsecurity.facebook.filter.type='redirect'
grails.plugin.springsecurity.facebook.domain.classname='mvp.FacebookUser'
grails.plugin.springsecurity.facebook.domain.appUserConnectionPropertyName='user'
grails.plugin.springsecurity.facebook.appId='<APPID>'
grails.plugin.springsecurity.facebook.secret='<SECRET>'
grails.plugin.springsecurity.facebook.filter.redirect.failureHandler='redirectFailureHandlerExample'
grails.plugin.springsecurity.facebook.autoCreate.roles=['ROLE_USER', 'ROLE_FACEBOOK']
I don't think it matters for this problem, but I have a FacebookAuthService that implements create() to search for existing users with the same email address as the Facebook user, and merges the accounts if it finds one. Currently my redirectFailureHandlerExample does nothing but log a message, which is never hit.
Any help greatly appreciated!
You should set the following setting too at config.groovy
grails.plugin.springsecurity.facebook.filter.redirect.successHandler='redirectSuccessHandlerExample'
And at the resources.groovy:
beans = {
redirectSuccessHandlerExample(org.springframework.security.web.authentication.SimpleUrlAuthenticationSuccessHandler) {
defaultTargetUrl = '/rar/user/home'
}
}
Following is the code i'm using for prog login for my application.
UsernamePasswordAuthenticationToken token = new UsernamePasswordAuthenticationToken(userName, passWord);
token.setDetails(new WebAuthenticationDetails(request));
authentication = authenticationManager.authenticate(token);
LOGGER.debug("Logging in with [{}]"+ authentication.getPrincipal());
SecurityContextHolder.getContext().setAuthentication(authentication);
after this a model is returned (without changing URL, i can see usename n role here). on that view, there is a form. which submits to another link with role permission same as of current user.
but when user submits the form then spring redirects it to login page and invalidate the session.
I have checked and found that jsession is is appended with .undefined (mS5YoJL3YfznQNuItNUeiLd6.undefined) and i suspect that this must be the problem.
I've checked it, and undefined was coming because of Jboss AS 7.1 and this whole issue was coming because I was not creating session while auto login. I have changed the code and its running perfectly. Thanks for your response. –
We are trying to get this working in JBoss EAP 6.2 but for the moment we haven't been able to find the reason why it is failing.
In our application, super users are able to decide which role they want to use after login in the application. So first the user will have a role and then we want to change it. For this we are doing the following:
Subject sub = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
for (Principal p : sub.getPrincipals()) {
if ("Roles".equals(p.getName())) {
SimpleGroup group = (SimpleGroup) p;
group.removeMember(new SimplePrincipal(CONSTANT_SUPER_USER));
group.addMember(new SimplePrincipal(authorizationRole));
}
}
This is actually changing the role in the Subject. But afterwards when the authorization is being checked we get the following in the server's log:
[org.apache.catalina.authenticator] (http-/0.0.0.0:8080-11) We have cached auth type LOGIN for principal GenericPrincipal[userName(superuser,)]
As you can see, it is still getting the old value after modifying it.
We are using our own class extending SimplePrincipal. Checking the content of Faces.getRequest() we have seen that the request contains an userPrincipal of type JBossGenericPrincipal and inside it, it contains our extended SimplePrincipal. Checking both of them we have seen that:
JBossGenericPrincipal.roles contains superuser
JBossGenericPrincipal.subject.principals contains the modified SimpleGroup with the new authorization role
Just for your information, we had this working on Wildfly first and it worked perfectly, but we had to change to JBoss and found that this wasn't working properly. So we think it has to be something related to this specific JBoss version.
Has someone faced this problem? Any idea why this might be failing? I guess we need to put the correct role in JBossGenericPrincipal.roles somehow, but... how?
Any help is appreciated. Thanks!
Seems Red Hat doesn't recommend changing the roles after the authentication has been done. So the only solution was to logout and re-login the user with the new role.