[Design of Security on JBoss] - Re: GSSAPI/Negotiate
by carstenKlein
@Mark: We have implemented a KerberosLoginModule for JBoss, that can be used in a fat client szenario. How is works:
1. The client part of the LoginModule creates with the GSS-API a Kerberos Service Token for the Service Principal of the server. To get the Service Token, the GSS-API needs the Ticket-Granting-Ticket (TGT) of the user. The Standard Krb5LoginModule can be configured to get the TGT from cache - that is what you typically want.
2. The client part of the LoginModule encodes the Service Ticket in base64 and put the ticket into the credentials of the SecurityAssociation of JBoss - like a password.
3. The server part of the LoginModule decodes the Service Ticket.
4. The server part of the LoginModule validates the Service Ticket with the GSS-API. To validate the ticket, the GSS-API needs the private Service Key of the server. That is typically deployed in a keytab. The Standard Krb5LoginModule can be configured to obtain the Service Key from the keytab.
All that GSS-API and Kerberos stuff is well documented: http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/index.html
@JBoss: What is about the SPNEGO/Kerberos support. I have not seen any production ready LoginModule yet. I am VERY interested in such an LoginModule for Tomcat and JBoss AppSrv.
Why do you investigate so much time in getting role / group informations from the active directory? In an enterprise context the active directory is an out-sourced infrastructure service. That is not the right place to define roles (other than infrastructure roles) for thousands of users and houndreds of applications!
I think it would be enough to autenticate a user with Kerberos and get the application roles from another (application specific) LoginModule - without authentication. So why should we make things more complicated?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130343#4130343
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130343
18 years, 1 month
[Design of the JBoss EJB Container] - Remoting issue
by ron.sigal＠jboss.com
A thread in the Remoting user forum ("JBREM-877: New Socket Connection is being Created for Every" - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=126382) has brought up an interesting issue concerning the use of Remoting in EJB3.
In AS 4.0.4/4.0.5, when EJB3 was using Remoting 1.4.x, each call to org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke() created a new org.jboss.remoting.Client, and when it returned, it left the underlying client invoker intact in the org.jboss.remoting.InvokerRegistry. The next call found the existing client invoker and reused its socket pool. (Simplifying somewhat, but basically true.)
Now, in AS 4.2.x/5.0.0, each call to InvokeRemoteInterceptor.invoke() calls Client.disconnect() before returning, which, if the reference count of the underlying client invoker goes to zero, leads to the destruction of the client invoker, along with its socket pool. So, unless there are multiple proxies in the same JVM running simultaneously and keeping the client invoker's reference count above zero, each invocation will lead to the creation of a new socket. The guy that posted JBREM-877 says that performance is 25% of what it was in AS 4.0.4.
One solution would be to add a feature which allows a delay in the destruction of the client invoker. E.g., the invoker locator
| socket://${jboss.bind.address}:3873/?invokerdestructiondelay=5000
|
would introduce a 5 second delay before the client invoker gets destroyed, increasing the probability that it would be reused. The default behavior would be to destroy the client invoker immediately.
Any thoughts from the EJB3 team?
-Ron
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130313#4130313
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130313
18 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces
by ataylor
anonymous wrote : 1) Delete a single message from a queue
| 2) Move a single message from one queue to another (e.g. to DLQ or expiry queue).
| 3) Expire a message
| 4) Change message priority
sounds good, via message id i guess.
anonymous wrote : 1. Change a header on a message
| 2. Drop a user connection
| 3. Drop a single subscription.
All good, especially the second one.Would this force the client to reconnect in a clustered environment?
anonymous wrote : 1. List connections for a user
| 2. View statistics for a user (number of messages sent, number of messages consumed etc)
first one trivial, I'll have to investigate the second!
anonymous wrote : Block a user, freeze a user out.
Again, i'll investigate!
anonymous wrote : List temporary destinations
|
| List sessions
trivial, I'll add.
anonymous wrote : listAvailableAddresses (these are the "routes").
|
| on the jms interface we should have
|
| listAllQueues
| listAllTopics
again, trivial, so i'll add.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130299#4130299
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130299
18 years, 1 month