JBoss 7.1 Final authorization with more than username and password

[sraue]

We have managed to set up security for a test ear with an ejb-jar containing a stateless session bean and could access the session bean with a remote client.

We used the Database login module.

Now the problem: Our real application is multi mandator aware. Therefore we need a custom login module which not

                          only gets the username and password but also the mandator name to be able to authenticate the respective user.

                          Our application is running perfectly on jboss 4.2.2GA with a custom login module. We used jaas to get username mandatorname and password

                          from the remote client to the jboss/our login module. Now there seems to be only one jaas callback handler in jboss 7.1

                          - org.jboss.as.domain.management.security.JaasCallbackHandler - which does not support custom callbacks (e.g. for the mandator name).

                          Is there any solution to our problem, please?

[dlofthouse]

In the previous AS version how did you get this additional field from the remote client into the AS server for the authentication step?

[sraue]

On the client:

SecurityAssociation.setServer();

SecurityAssociation.setPrincipal( new ApplicationPrincipal( user, mandator ) );

SecurityAssociation.setCredential( password.toCharArray() );

where user, mandator and password are strings and ApplicationPrincipal

is a bean which implements java.security.Principal and java.io.Serializable

holding user name and mandator name.

Our login module extends org.jboss.security.auth.spi.AbstractServerLoginModule

and does in the login method:

....

SecurityAssociationCallback sa = new SecurityAssociationCallback();

Callback[] callbacks = { sa };

callbackHandler.handle(callbacks); // callbackHandler from call of initialize method

Principal identity = sa.getPrincipal();

if ( !( identity instanceof ApplicationPrincipal ) ) {

    throw new FailedLoginException( "No valid RichPrincipal given." );

}

ApplicationPrincipal p = ( ApplicationPrincipal )identity;

// check if mandator user and password match

....

[dlofthouse]

If the user and mandator together represent the user could you concatanate the two together into a single String in a similar way as happens often for realms e.g. user@realm or realm\user.

[sraue]

Yes, that's true but in real life our ApplicationPrincipal holds a lot more information - we (mis)use it to transfer e.g. filter adjustments which control which data are computed and fetched by our ejbs.

These "hidden parameters" would blow up our ejb api's. We have a very big ejb application which needs those "hidden" parameters in quite a lot of places.

[kieselhorst]

Same problem here...did you already solved it?

[henrikdeluxe]

i've got this problem to - is there no way to pass custom principal from remote client to serverside loginmodule?

did anyone worked out an alternative to get the additional client informations useable on serverside?

[kieselhorst]

Look here: ejb-security-interceptors: Using client and server side interceptors to switch the identity for an EJB call.

[henrikdeluxe]

thanks Dennis,

i allready had seen this quickstart and reviewed weather it could help solve my problem

i stopped that after deciding this quickstart is overcomplexed for my concern, cause i dont want to change the clients identity within the same connection

i will take a closer look at this quickstart again, may you can point me to an special part of this quickstart according to my concern

[dlofthouse]

Henrik - In addition to a username and password what additional data are you trying to send from the client to the server?

[henrikdeluxe]

Hi Darran,

thanks for your interest

im sending various information with my principal

• username (String)
• unique sessionID (long)
• descripton of client application (String, may could be enum too)
• username from os (String)
• hostname of the computer where the client is running (String)

the bold marked are essential for me, the other two are currently just for logging and maintainance

Here an example why i need the sessionID:

for my concern its possible that the same user opens multiple instances of the same client application.

For example if the user open an dialog for editing an entity, there is a part in my business logic that mark that entity locked by the sessionId i get from EJBContext.getCallerPrincipal().

If the same user works on multiple clients and start editing the lock only should be assigned to this client instance.

this is only one important use case i use my custom principal in my application deployed on AS 5

Now i'am guessing how to pass this information with the new remoting system.

Whatever i try do i only get SimplePrincipal from SecurityAssociationCallback in my LoginModule.

Cause i'm set module option <module-option name="principalClass" value="de.ejb.remote.server.security.MyAppPrincipal"/> i retrieve an MyAppPrincipal when calling EJBContext.getCallerPrincipal() but not that one i passed over in my client.

[dlofthouse]

Reading your description it sounds to me that strictly speaking these pieces of information that you are using are outside of the actual authentication of the remote user, I appreciate that in previous AS releases you have been able to bundle these pieces of information with the authentication process to make them available on the server side but it doesn't feel like a justification for bundling them during the authentication process.

If there is a case for additional information to be passed for the purpose of authentication I am open to considering an enhancement to the SASL libraries we are using to support the sending of additional fields but it would need to be for the purpose of authentication.  Are any of the fields you list here actually used in the authentication process.

The use case of a client instance having a unique session ID that is used to control concurrent access to data sounds to me like something that should be handled in client and server side interceptors as in the quick starts mentioned but kept separate from the actual authentication of the remote user.

[henrikdeluxe]

thank you Darran, so it's not possible what i'm trying to do actually?

im not using these addtional informations directly in my LoginModule, but im pass through the principal i'm getting from SecurityAssociationCallback to the getIdentity() method. So whenever i've called EJBContext.getCallerPrincipal() in an secured EJB i got exactly that custom principal regarding to the calling client.

So your advice is, i should get familar with client/serverside interceptors to redevelop my functionality instead of invest my time to migrate my old code?

[kieselhorst]

It is possible. You only need to adapt the mentioned quickstart sample to transfer the custom principal using the EJBClientInvocationContext.

[dlofthouse]

The problem with the quickstart approach for you is that it relies on first establishing an authenticated connection to the server, then at the time of the EJB invocation a second authentication occurs which is where the interceptors come into use and send additional data for use during the authentication step.

If you really want all of this data to be sent in and used during authentication an alternative may be to construct a specially formatted username which contains all of these fields, the security realm can then delegate to JAAS where a login module can de-construct the username into it's associated components.

But as I say, if this is more of a case that bundling data during authentication was just a solution found in AS5 to get this data to the server and it is not actually a part of the authentication process it may be more appropriate to try and separate the two concepts so you have the user authenticating with the server just using their username and password and then use the interceptors to send non-security data to the server with the request.