[Design of Security on JBoss] - SASL Authentication
by mikezzz
Hi,
Over at http://www.buni.org we need to implement SASL authentication for our IMAP support. We need it to integrate with the JBoss implementation of JAAS. Therefore I have placed a patch for SASL Authentication in the security JIRA project (against the 4.0 branch): http://jira.jboss.com/jira/browse/SECURITY-36
Currently it only supports CRAM-MD5 (DIGEST-MD5 should only be matter of extending the configuration and GSSAPI might require a bit more thought) and doesn't support initial response yet.
I do have commit access so if you are happy with this code, let me know if you like me to add this. It would be useful for us if we could get this into the next stable release.
How to use the SASL authentication:
The SASL support is an extension to the UsernamePasswordLoginModule so it is available for all authentication repositories (e.g. Database, LDAP, etc.). To enable it add the following configuration:
<authentication>
| <login-module code = "..."
| flag = "sufficient">
| <module-option name = "sasl.enabled">true</module-option>
| <module-option name = "sasl.encoding">base64</module-option>
| <module-option name = "sasl.hostname">localhost</module-option>
| <module-option
| name = "sasl.mechanism">CRAM-MD5</module-option>
| </login-module>
| </authentication>
Client code then needs to pass the challenge/response data as base64 encoded strings using the TextInputCallback/TextOutputCallback. Also should handle the NameCallback to get username of the client trying to authenticate.
CallbackHandler ch = new CallbackHandler() {
| public void handle(Callback[] callbacks) throws
| IOException, UnsupportedCallbackException {
| for (int idx = 0; idx < callbacks.length; idx++) {
| Callback cb = callbacks[idx];
| if (cb instanceof NameCallback) {
| NameCallback nc = (NameCallback) cb;
| } else if (cb instanceof TextInputCallback) {
| TextInputCallback tic = (TextInputCallback) cb;
| byte[] response = receive(); // Gets the response
| String s = Base64.encodeBytes(response);
| tic.setText(s);
| } else if (cb instanceof TextOutputCallback) {
| TextOutputCallback toc = (TextOutputCallback) cb;
| String s = toc.getMessage();
| byte[] challenge = Base64.decode(s);
| send(challenge); // Send the challenge to the client
| }
| }
| }
| };
|
| LoginContent lc = new LoginContent("...", ch);
| lc.login();
For more information check the SaslLoginTestCase.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4027950#4027950
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4027950
19 years
[Design of JBoss Remoting, Unified Invokers] - Re: Bisocket server invoker NPE
by timfox
"ron.sigal(a)jboss.com" wrote : I looked at some old logs, and it looks like the problem is associated with tests that deliberately kill the server
|
Yes, I noticed this during crash and failover tests.
anonymous wrote : The NullPointerException seems to occur because the client invoker has closed before the ControlMonitorTimerTask has stopped running. I'm not sure how this is happening, but it could be that the TimerTask was in the middle of running when the client invoker closed.
|
When using a timer, you can ensure the task has finished running by doing the following:
(from java.util.Timer javadoc - cancel method)
anonymous wrote :
| Note that calling this method from within the run method of a timer task that was invoked by this timer absolutely guarantees that the ongoing task execution is the last task execution that will ever be performed by this timer.
|
So you just need to add a sychronized stop() method to the TimerTask which calls cancel() and make sure you call this from your code - take a look at org.jboss.messaging.core.plugin.postoffice.cluster.StatsSender which does something very similar.
anonymous wrote :
| In any case, I've modified the code to avoid the NPE and print a warning message.
|
Is a warning message really appropriate? A warning would imply something wrong or strange - but this is to be expected.
anonymous wrote :
| I ran the JBM functional tests, and they all pass except for occasional failures in FailoverValveTest at line 287
|
|
| | assertNotNull(o);
| |
|
| I reran FailoverValveTest with the remoting jar from the SVN repository and the same thing happened, so I don't think I broke anything new.
FailoverValve is not currently used so I wouldn't worry too much about this. We need to address this in the test suite.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4027942#4027942
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4027942
19 years