[jboss-jira] [JBoss JIRA] (AS7-6367) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms

[jaikiran pai (JIRA)]

    [ https://issues.jboss.org/browse/AS7-6367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761371#comment-12761371 ] 

jaikiran pai commented on AS7-6367:
-----------------------------------

A bit of background to this issue. Currently the EJB3 subsystem allows pointing to just one remoting connector (configured in the remoting subsystem):

{code}
<subsystem name="ejb3"...>
   <remote connector-ref="foo" thread-pool="default/>
...
{code}
The "foo" connector is in turn configured in the remoting subsystem. The foo connector is backed by a security-realm. Effectively, this means that all remote EJB communication that happens will happen via the foo connector and as a result will use *only* that single security-realm.

The goal of this JIRA task was to allow the EJB3 subsystem to point to more than 1 remoting connectors configured in the remoting susbystem so that remote applications can then choose from these available remoting EJB connectors for EJB communication.

This looked straightforward to implement when I initially started work on this. All I had to do was allow something like:

{code}
<subsystem name="ejb3"...>
   <connectors>
     <remote name="one" connector-ref="foo" thread-pool="default/>
     <remote name="two" connector-ref="another-one" thread-pool="default"/>
     ...
   </connectors>
...
{code}
instead of the previous configuration. But when I started implementing this I realized that it isn't straightforward keeping in mind the backward compatibility goals. It took a (long) while to get the transformers right for these configurations. As of today, I've the transformers functional and the above changes are working. However, while doing some manual testing around this, I've realized that our previous model/xml had a incorrect notion of configuring channel-creation-options for the remote EJB connector. It allowed something like:
{code}
<subsystem name="ejb3"...>
   <remote connector-ref="foo" thread-pool="default>
            <channel-creation-options>
                <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
                <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
            </channel-creation-options>
   </remote>
...
{code}
Those channel-creation-options were then used while registering a EJB channel handling service against the remoting Endpoint. Now with the changes were are proposing, this will no longer work out - i.e. each remote connector configuration in the EJB subsystem *cannot* be allowed to specify different channel-creation-options. In fact, it doesn't belong to the individual connector and instead it should be at the EJB subsystem level since that service should be registered just once. So this is going to require a lot more (re) work to implement this feature.

I'm currently working on this one and have a different schema/model in mind. Something like:

{code}
<subsystem name="ejb3"...>
   <!-- Remote element represents the "remote" aspects of a EJB subsystem and doesn't necessarily
    mean a remoting connector. In fact, that was the original goal when this element was introduced, but
    got messed up somewhere down the line -->
   <remote>
      <!-- The remote aspect of a EJB susbystem can have connectors -->
      <connectors>
            <!-- A connector which is backed by remoting subsystem -->
            <remoting-connector connector-ref="foo" thread-pool="default"/>
            <!-- Possibly n future a HTTP connector 
                <http-connector ..../>
            -->
      </connectors>

      <!-- Notice that now we have these channel-creation-options outside of the individual connectors so that they are applicable to the entire EJB subsystem -->
   
      <channel-creation-options>
                <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
                <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
      </channel-creation-options>
      ...
   </remote>     
....
{code}
This is going to take some work to get it functional. I'm working on this one in parallel with some other tasks. I'll update this JIRA once this gets done.

                
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-6367
>                 URL: https://issues.jboss.org/browse/AS7-6367
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.1.3.Final (EAP)
>            Reporter: Derek Horton
>            Assignee: jaikiran pai
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients.  For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain.  In both of those situations, it seems that the
> EJBs are limited to a single authentication point.  The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules.  I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this:  the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain.  Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira