need advice

[kosl]

Hi,

I need advice. I'm working on security and the standard resouce securying via web.xml and j_security_check doesn't fit my needs. I would like to achieve such goals:

- Change the standard scenario: when user tries to access secured area he is redirected to login page - and then after successful authentication - get's access to secured resources. I would like to be able to redirect him sometimes first to some other page - for instance page forcing him to change the password - and only then to the requested resource,
- be able to put the login-form on any page and after logging in redirecting back to that page,
- requesting re-authentication for specific resources (and protecting access to them via SSL
- etc.

I've developed my own LoginModule and it's working perfectly but the standard solution with j_security_check and tomcat doesn't seem to fit my needs.

My question is where should I look for any information about how to achieve my goals? I've looked to the Jboss administraiton guide but still I'm not sure what to do.

Will I have to change/add something to JBoss source code?

I would be very grateful for any advice.

With Kind Regards,

Karol Oslowski

[markash]

Good Day,

Try the following...

http://securityfilter.sourceforge.net/

NOTE: I am not affiliated to the project presented in any way.

[kosl]

Thanks for your answer. I looked at this project already before unfortunatelly I didn't manage to integrate it with jboss (4.0.3 SP1). Any other clues?

Regards,

k.

[markash]

Good Day,

What were the issues? It seems that it is using web filters whish are part of the servlet specification and should not need integration.

[kosl]

Well, I think it needs integrating since the results of authentication done by securityfilter must be "caught" by JBoss web layer and ejb layer. I tried to describe my problems http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90372.
but I got no answer.

I guess the problem lies in this method:

 public Principal authenticate(String username, String password) {
 try {
 SubjectSecurityManager subSecMgr = getSecurityManager();
 SimplePrincipal p = new SimplePrincipal(username);
 char[] pChars = password.toCharArray();
 if (subSecMgr.isValid(p, pChars)) {
 SecurityAssociation.setPrincipal(p);
 SecurityAssociation.setCredential(pChars);
 return p;
 }
 } catch (Exception e) {
 log.debug(e);
 }
 return null;
 }

SecurityAssociation is not in the API and since this code is quite old I guess it simply doesn't work any more with the new version of JBoss.

Thank you very much for your help so far ;-)

k.

[markash]

Good Day,

The SecurityAssociation is used by the ClientLoginModule to stuff the Principal and Credentials into the calling threads context so that this can authenticated by the security inteceptors before a EJB call is processed.

Is a SecurityException being thrown because the ClientLoginModule makes use of PrivilegedAction implemented in the internal class SecurityAssociationActions.

Try changing the java security policy for the code to all or use a PrivilegedAction.

 /**
 * Set the current principal information. If a security manager is present,
 * then this method calls the security manager's <code>checkPermission</code>
 * method with a <code> RuntimePermission("org.jboss.security.SecurityAssociation.setPrincipalInfo")
 * </code> permission to ensure it's ok to access principal information. If
 * not, a <code>SecurityException</code> will be thrown.
 * @param principal - the current principal identity.
 */
 public static void setPrincipal(Principal principal)
 {
 SecurityManager sm = System.getSecurityManager();
 if (sm != null)
 sm.checkPermission(setPrincipalInfoPermission);

 if (trace)
 log.trace("setPrincipal, p=" + principal + ", server=" + server);
 if (server)
 {
 threadPrincipal.set(principal);
 }
 else
 SecurityAssociation.principal = principal;
 // Integrate with the new SubjectContext
 SubjectContext sc = threadSubjectStacks.peek();
 if( sc == null )
 {
 // There is no active security context
 sc = new SubjectContext();
 threadSubjectStacks.push(sc);
 }
 else if( (sc.getFlags() & SubjectContext.PRINCIPAL_WAS_SET) != 0 )
 {
 // The current security context has its principal set
 sc = new SubjectContext();
 threadSubjectStacks.push(sc);
 }
 sc.setPrincipal(principal);
 if (trace)
 log.trace("setPrincipal, sc="+sc);
 }

[kosl]

Thank you very much,

I would be grateful for any informations on how to
change the java security policy for the code to all or use a PrivilegedAction?
If this is a stupid question I'll look for it on my own.

I hope this would help and as soon as I'll succed to implement it I'll write here about the results.

Regards,

k.

[anil.saldhana]

I would like to warn that it is better to have your custom security solution rather than relying on the container auth, if you have complex use cases and requires deeper integration with tomcat and/or JBossSX. The issue is implementation details change over time.

[kosl]

Well, I'm aware that probably it would be better to have a custom security solution but that's what was my question about - where to find information about how to develop such a custom solution?

[kosl]

And I guess probably it would be better to buy such a solution then to develop it....