Do you have the latest jbosssx-client.jar from security 2.0.0.snapshot? That internally has the routing for SecurityAssociation to security context concepts. So your SecurityAssociation.xxx calls internally do the security context work.
We are moving away from the security association usage.
In theory, you should be doing a jaas login.
If there are any specific tests that you want me to take a look at, please point them here. The security context usage over the old SA is an important step towards the future security project. I do not want to hold off any WS deliverables because of this new introduction.
Additional details for http://jira.jboss.com/jira/browse/JBAS-4317
Thomas, the security context either comes over the wire (remote calls) or comes from the thread local (Local EJB invocations). So where-ever the Invocation object is created on the server side, the security context needs to be set on the Invocation object. The IllegalStateException thrown in the containers was one way of validating that whoever was creating the Invocation object has set the security context (just the way they would have done with .setPrincipal, setCredential etc). The primary issue is that there are various integration layers constructing the Invocation object rather than a central place. Some of the examples where the Invocation object is created on the server side include the BaseLocalProxyFactory, ProxyFinderFactory, CMPFieldBridgexxxx. So I will need to revert back the IllegalStateException and need your stack trace so that I can understand where your Invocation is being created. Once the containers have established that the invocation does contain a security context, they set it on the thread local so that the JACC PolicyContext get Subject call always takes care of the RunAsIdentity that came into the specific container. I personally feel that we need some kind of an Invocation creation factory on the server side. Please look at ProxyFinderFactory (remote ejb) and BaseLocalProxyFactory for guidance on how to pick the security context from invocation on the wire or thread local for local ejb.
A discussion with thomas has brought out an issue for me.
The background is that a security context can come over the wire for remote calls. Now whoever is constructing the invocation object on the server side has to be aware of this change (ie. they can set a SecurityContext on the session).
Given this, the containers (session,entity) have two choices:
a) Ensure that there is a security context on the invocation.
b) Accommodate any integration code (that may have created their own Invocation object and forgotten to set the security context) and create the security context on the inv. This can be bad because things like runas or any tokens that may be coming over the wire may be lost.
I prefer a) but may break clients.
In general that has to be a security aspect in the call chain to ensure a proper security context. This gets back to the cluster question you had earlier. The form of the incoming security context may need to be mapped into another form. Any existing usage of the SecurityAssociation outside of a security interceptor is broken code. Either it needs to be using a public authentication api, or it needs to be moved into a security aspect that can be kept in sync with implementation details.
The current issue is an implementation/integration issue. Whoever is constructing the Invocation object on the server side has taken care of setting the principal and cred, but has not dealt with the security context.
The ejb containers can ensure that there is a security context on the invocation (somebody has to do this before the security processing starts). I think I am going to stick with the explicit requirement that any invocation coming into the containers have the security context set on the invocation, by the invocation builders on the server side.
In reality, we do not need the principal and the credential on the invocation because the security context would anyway contain them.
There can be a chain of security interceptors right after the containers on the call path. So the security context has to be established on the server side.
The client side security interceptors take care of constructing a security context and then send it on the invocation over the wire. Now if the server side invocation constructors ignore the sc that came on the wire, it is bad.
I think we really need some type of Invocation construction factories that take care of such concepts. Every integration layer (ProxyFactory, BaseLocalProxyFactory, CMPFieldBrigdexxxx, WS integration layer) who are constructing the Invocation objects can use the factories.
I had a discussion with Scott on this. The invocation object creators should not be dealing with the security aspects. I will need to establish the security aspects via an interceptor after the container.
For the client side, people should not be doing any direct SecurityAssociation stuff. JAAS is ok. The security project should really be providing a client SPI for clients to use. JAAS etc should be an internal detail of the SPI. GSS/SASL type of framework is where we intend to go towards that will provide pluggable aspects semantics for security.
JAAS is decent but it is cumbersome. We have to provide a Client side SPI for usage.