re-authentication and pooling

[dimonv]

Hello,

I have seen several topics in the JCA forum discussing different issues, which could be solved by the re-authentication feature. I guess in our situation this is also the case.

We are using a third party JCA resource adapter providing connections to the CORBA services. The CORBA services have different interfaces. We have to authenticate the user requesting a connection and using then the authentication mechanism:

<security-domain-and-application>

which causes that the connections are pooled by the Subject and their types. Now regarding the connection pool size. For example:
500 application users (different identities)
70 different connection types
20 max pool size (each sub-pool)
1 min pool size (each sub-pool)

The result of this scenario is that the pool can grow up to 500*70*20=700000 connections.

Well, at the moment our pool size do not achieve this level, but the number of application users tend to grow.

Considering this scenario the re-authentication would allow to have just one common pool for all connections and re-use them for every identity.

I would very appreciate if the re-authentication is considered by the pooling implementation in JBoss. Since JCA does not restrict the number of the types/interfaces of the connections provided by a resource adapter, I can imagine that there could be many other resource adapters and their users, which will surely benefit from this feature.

Thanks and kind regards,
Dmitri

[jesper.pedersen]

I have created https://jira.jboss.org/jira/browse/JBJCA-94 as a placeholder for reauthentication support for the JBJCA project.

If you want to discuss the design and implementation of the functionality feel free to drop by the JCA developer forum. Patches is of course most welcomed :)

[dimonv]

Hi Jesper,

Do you mean I have to create a new topic in the "Design of JCA" forum?

Regards

[jesper.pedersen]

Only if you want to discuss and help with the implementation of the functionality - otherwise just keep an eye on the JIRA.

[jesper.pedersen]

http://community.jboss.org/wiki/Reauthentication

[dimonv]

Sorry, but I'm a bit confused. http://issues.jboss.org/browse/JBJCA-94 is still unresolved.

Could you please explain in which version is this feature available? In which AS version? Is there a backport for AS 4.2.3?

Thanks

[jesper.pedersen]

Sorry, but I'm a bit confused. http://issues.jboss.org/browse/JBJCA-94 is still unresolved.

Yes, because development is still on-going. You are welcome to help out.

Could you please explain in which version is this feature available? In which AS version?

I'm currently targeting JBoss Application Server 7.0

Is there a backport for AS 4.2.3?

As always - backports are community tasks.

[dimonv]

You wrote in your article:

There are a couple of design choices

1. An implementation that keeps all connections within the same managed connection pool
2. An implementation that separates connections based on their credentials and does a reauthentication if needed

None of the options provide a solution for the issue described in the original post:

• the fact that a JCA resource adaptor may support multiple types of the underlying connections. That means - pooling by CRI at least.
• pooling by Subject (I pressume you mean it with credantials) may cause too many sub-pools in case of a big numgber of users. The consequence is that max pool size = max pool size x number of users.

In my opinion the pooling should depend on the re-authentication capability of adapter. If an adapter declares that it supports re-authentication - pool by CRI, if not - pool by Subject and CRI.

[jesper.pedersen]

None of the options provide a solution for the issue described in the original post:

• the fact that a JCA resource adaptor may support multiple types of the underlying connections. That means - pooling by CRI at least.
• pooling by Subject (I pressume you mean it with credantials) may cause too many sub-pools in case of a big numgber of users. The consequence is that max pool size = max pool size x number of users.

Because the original post is wrong. Read section 9.1.9.

In my opinion the pooling should depend on the re-authentication capability of adapter. If an adapter declares that it supports re-authentication - pool by CRI, if not - pool by Subject and CRI.

Wrong again.

Pooling for reauthentication enabled resource adapters is a special pool implementation (Reauth) - not PoolByCri, PoolBySubject, ...

And it is up to the resource adapter to manage its ManagedConnection connections in regards to reauthentication, so the implemented solution works.

You need to implement the contracts defined in the JCA specification - if you have multiple Connection's using the same ManagedConnection - then that it is a matter for the resource adapter - not the JCA container.

[dimonv]

Sorry, but this topic is about two years old and refers to the code base from AS 4.2.3.GA and I was trying to find a solution for a real issue, which has never been commented here. I spent about an year on discussing it in EAP support portal and then was invited to discuss in the community.  Can you explain please what is wrong. What do you mean with:

Because the original post is wrong.

You are using a reference to it in JIRA and in your article.

In the previous message I commented the article's chapter "Design" and not the implementation in IronJacamar. I looked at ReauthKey in the trunk. It does't even use CRI neither in its equals() method not elsewhere.

I wrote:

a JCA resource adaptor may support multiple types of the underlying connections

I meant several Java types e.g. EJB business interfaces, File/Path, Http/Https-Connections any specific classes from a hierarchy etc.. And this information may be a part of CRI. And if a requested connection should support e.g. HTTPS but if a connection obtained from the pool is an insecure one it is wrong. Read section 6.5.1.2.

[jesper.pedersen]

Yes, and I quote "These properties remain opaque to the application server during the connection request flow.".

It is up to the JCA container to provide pooling of managed connections (not the connections) and implement that pool such that the resource adapter provider can count on the requirements specified in section 9.1.9.

You have to implement section 9.1.9 and keep track of the relationship between a connection and its managed connection. Just like always.