[Design of Security on JBoss] - Custom Principal Propagation Related
by anil.saldhana@jboss.com
I have a usecase where there is a clear mismatch on what is put on the SecurityAssociation thread local principal stack and what you really want.
Usecase:
* User logs into a web application with form auth.
* JBoss Security Mgr creates a SimplePrincipal of the username and passes to the Jaas framework.
* A login module creates a custom view of the username via a Custom Principal and into the shared state map.
* ClientLoginModule populates the SA threadlocal stack with the custom principal.
* Now that the form authentication is fine, the JBossSecurityMgrRealm populates the SA stack with subjectcontext.
Now in the servlet, the user makes a call on an ejb (no jaas login). This time the security interceptor in the proxy picks up the principal on the SA stack (which happens to be the SimplePrincipal).
I think this case falls through the crack for providing end-to-end security.
Workaround:
a) Have an explicit jaas login in the servlet such that the ClientLoginModule places the custom principal again on the SA stack. Issue is that there needs to be a way for the password to be obtained.
b) Provide an additional option on the JBossSecurityMgrRealm to plug in a custom principal class, such that this principal class gets pushed on the SA stack rather than the simple principal.
I like option b)
Any other thoughts?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973351#3973351
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973351
19 years, 6 months
[Design of JBoss Admin Console] - Re: JBossMQ vs JBoss Messaging
by chilin
The webtest reported a couple of failures running against the ?all? server configuration. Some of the failures can be resolved by specifying the server name at run time, however the failures in the JmsPageTest are a little harder to resolve! Basically the test was written expecting the changes made to the JBossMQ services (e.g. MessageCache, PersistenceManager, and StateManager) are hot deployable. However with the ?all? server, the configuration files for JBossMQ are deployed under the deploy-hasingleton/jms directory. When changes are made to the config files (e.g. hsqldb-jdbc2-service.xml, hsqldb-jdbc-state-service.xml), the new values are not reflected in the mbeans until the server is restarted. This caused the JmsPageTest to fail while verifying the changes.
The Admin Console?s readme file does indicate the webtest must run against the ?default? server. Looks like we?re telling the truth here!!!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973326#3973326
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973326
19 years, 6 months