Priority of connection selection when using security-domain-

[starksm64]

When using the security-domain-and-application connection selection criteria, any Subject identity is given preference over the ConnectionRequestInfo in the BaseWrapperManagedConnectionFactory.getConnectionProperties method:

 protected Properties getConnectionProperties(Subject subject, ConnectionRequestInfo cri)
 throws ResourceException
 {
 if (cri != null && cri.getClass() != WrappedConnectionRequestInfo.class)
 {
 throw new JBossResourceException("Wrong kind of ConnectionRequestInfo: " + cri.getClass());
 } // end of if ()

 Properties props = new Properties();
 props.putAll(connectionProps);
 if (subject != null)
 {
 if (SubjectActions.addMatchingProperties(subject, props, this) == true)
 {
 return props;
 }
 throw new JBossResourceException("No matching credentials in Subject!");
 } // end of if ()
 WrappedConnectionRequestInfo lcri = (WrappedConnectionRequestInfo)cri;
 if (lcri != null)
 {
 props.setProperty("user", (lcri.getUserName() == null)? "": lcri.getUserName());
 props.setProperty("password", (lcri.getPassword() == null)? "": lcri.getPassword());
 return props;
 } // end of if ()
 if (userName != null)
 {
 props.setProperty("user", userName);
 props.setProperty("password", (password == null) ? "" : password);
 }
 return props;
 }

It really should be the other way around as the ConnectionRequestInfo will always be the inner most specification. Setting the Subject entails some indirection rather than being directly passed in. Is there a valid reason why the Subject identity is given preference currently?

[adrian.brock]

This question came up before a few years ago.

See section 8.2 "Contract for ResourceAdapter" in the jca 1.5 spec.

Option C: it should only use the CRI if the AS passes a null Subject.

As I said before
security-domain-and-application
is really a misnomer.

For security, it always uses the security domain.
The "application" part really refers to other pooling parameters,
like whether it is queue/topic connection for jms.

[starksm64]

From the j2ee component level there is only Container and Application security. The problem is then really how we are creating the Subject when there is no inherent Subject. Today this requires an unauthenticatedIdentity setting on the associated security domain login module configuration, and there is no way to override this using the application supplied security context. The jca login modules could certainly support the notion of accepting the CRI security information in preference to the statically defined anonymous user identity. Nothing I read in the j2ee_connector-1_5-fr-spec in section 9.1.8.1 Contract for the Application Server, indicates this cannot be done as there is the carte blanche 'implementation-specific security mechanisms and configuration' phrase in the beginning:

9.1.8.1 Contract for the Application Server

The application server may provide specific security services, such as principal mapping and delegation, and single sign-on, before using the security contract with the resource adapter. For example, the application server can map the caller principal to a resource principal before calling the createManagedConnection method to create a new connection under the security context of the resource principal.

In container-managed sign-on, the application server is responsible for creating a Subject instance using its implementation-specific security mechanisms and configuration. This should happen before the application server calls the createManagedConnection method of the ManagedConnectionFactory. The resource adapter is driven by the application server and acts as consumer of security information in the created Subject.

I have a testcase scenario where I'm testing the different jca login module interaction with other j2ee components security contexts, and I need to access the database as an admin user to create the user with reduced permissions to validate in the context of the j2ee usage.

Do you see a reason why the anonymous identity/proof of identity should not be from the request context?

[adrian.brock]

The only reason it is not done is because the CRI is transparent to the AS.

If there was configuration in the login module to understand the CRI
and it had access to the CRI, I don't see why it couldn't create a Subject
from this information.

You would have to use the security-domain-and-application configuration
to make the pooling work correctly.

[adrian.brock]

Or maybe it would be easier for the login-module
to signal there is no Subject, allowing the MCF to use the CRI?

Our MCF's have a mechanism for defining a default login in the
MCF's properties.

[starksm64]

Ok, I see the problem with using the mcf and cri at the base connection manager level due to the opaqeness of these objects. This cannot be handled at the login module level because of another outstanding issue, building a jca Subject when there is a run-as identity. The issue here is that the run-as identity is not anonymous, but it also does not have an inherent PasswordCredential. The run-as is an assumed identity based that has one spec defined role, and may have other roles assigned to it in 4.x+ using an appserver specific deployment setting.

About the only thing I can see doing is updating the logic in getConnectionProperties to try to use the cri and then the mcf:

 WrappedConnectionRequestInfo lcri = (WrappedConnectionRequestInfo)cri;
 if (subject != null)
 {
 if (SubjectActions.addMatchingProperties(subject, props, this) == true)
 {
 return props;
 }
 // If there is no PasswordCredential retry with one based on the cri
 if( subject.getPrivateCredentials(PasswordCredential.class).size() == 0 )
 {
 String criUser = lcri.getUserName() == null ? "": lcri.getUserName();
 char[] criPW = lcri.getPassword() == null ? new char[0]: lcri.getPassword().toCharArray();
 PasswordCredential cripw = new PasswordCredential(criUser, criPW);
 subject.getPrivateCredentials().add(cripw);
 if (SubjectActions.addMatchingProperties(subject, props, this) == true)
 {
 return props;
 }
 // Else, repeat with the mcf default username/password ...
 }
 throw new JBossResourceException("No matching credentials in Subject!");
 } // end of if ()

Its not clear to me that the SubjectCriKey pooling key will work if the mcf defaults are included as I have not tracked down all the Subject based call paths.

[starksm64]

That definitely breaks the connection pooling as the selection of the InternalManagedConnectionPool is based on a Subject that does not have the PasswordCredential, but the pools map key is a Subject with this added in. There would have to be another pooling criteria key that only validated the equality of the Subject principals for this type of change to be effective, but then such a pool would not allow for the same user obtaining different connections based on different db login credentials.

[adrian.brock]

This is not something that should be handled at the ManagedConnectionFactory level.
We don't even write all the rars to add this behaviour.

I thought run-as was an authorization thing?

Whereas the JCA security is an authentication process.
Authorization is done by the underlying resource, e.g. the database.

[starksm64]

run-as is a grant of one or more roles to the call context, but the identity is not well defined. The authentication is essentially bypassed so this is a trusted activity. The issue is what control should exist at the jca layer to set the trusted identity. As far as the data source is concerned, this is the establishment of a Subject with a valid PasswordCredential because the jdbc driver is stupid and has no notion of allowing access based on a trusted context.

[adrian.brock]

Whichever identity you choose, it must be established before
it goes through the pooling layer, otherwise you could end up in the wrong subpool.

I assume no reauthentication support at the MCF layer:
http://jira.jboss.com/jira/browse/JBAS-1429

You should think of the pool as a broker that can switch requests to different
sets of connections based upon the security identity (if it is configured that way).

[adrian.brock]

I'm not entirely sure what you are trying to achieve?

Are you trying to use the run-as to login to the resource
or are you trying to only allow access to a resource
if it has a certain role?

i.e. do some authorization in the connection manager.

[starksm64]

Yes, that is clear after trying to integrate support for run-as. For now I'll just add knowledge of the run-as CallerIdentityLoginModule for the 4.0.1sp1 release and revisit this when the interceptors are added. I'll probably look at the reauth issue as another scenario to get the extraction of the security from the base connection manager layer.

[starksm64]

The real issue is providing the run-as roles to the resource adaptor for its authorization decisions. The lack of an explicit notion of how run-as can be propagated though the jca layer is the sticking point.

[adrian.brock]

Such a notion is not currently supported by the spec.

Appendix E 2: Requirements
"The connector architecture requires that the application server and the resource adapter must support the JAAS Subject class as part of the security contract. However, it recommends (but does not mandate) that an application server use the JAAS pluggable authentication framework.

The connector architecture does not require support for the authorization portion of the JAAS framework."

The only way I can see it being done at the moment is to have some
mapping at the connection manager level
from the run-as to a principal and credential that represents the
authorization you are trying to achieve.