Elytron integration - 1.3 branch - Resource Principal

[Flavia Rainone]

Hi everyone.

So, I'm kicking off the thread for discussing the integration with Elytron.

As we have the new branch and the old branches, I decided we could move on to looking the new branch, that currently has no security code (correct me if I'm wrong, Stefano) after we have seen how to integrate branch 1.3.

The security in IronJacamar concerns two main parts, one is the Resource Principal related stuff, in short we need to apply a sequence of rules as defined by the spec to provide a secure access to the EIS, regardless of whether the application server is responsible for authenticating or the EIS itself.

Another important part is the Security Inflow, that I will discuss in another thread.

So, the Security Architecture is mainly defined in the Chapters 8 and 9 of the JCA spec:
https://java.net/downloads/connector-spec/connector-1_7-spec-final.pdf

In short, we have two scenarios when the component requests for a new connection:
- pass along security information if component-managed sign-on is enabled:

// perform JNDI lookup to obtain connection factory
javax.resource.cci.ConnectionFactory cxf = (javax.resource.cci.ConnectionFactory)initctx.lookup(“java:comp/env/eis/MyEIS”);
// Invoke factory to obtain a connection
com.myeis.ConnectionSpecImpl properties = .. // get a new ConnectionSpec
properties.setUserName(“...”);
properties.setPassword(“...”);
javax.resource.cci.Connection cx = cxf.getConnection(properties);

- use a series of rules to determine the resource principal and preform sign-on if container-managed sign-on is enabled
// Invoke factory to obtain a connection. The security
// information is not passed in the getConnection method
javax.resource.cci.Connection cx = cxf.getConnection();

In this case, we have the possibility of having the resource princpal as a:
- configured identity: an identity configured to access the EIS
- mapped principal: the principal is defined as a mapping of the caller principal to the EIS
- impersonated caller principal: we are simply using the same caller principal and its credentials to access the EIS
- mapped crendentials: the principal is using a mapping of the credentials of the caller principal

The authorization could happen at the application server or at the EIS.

The resource principal is defined by the ConnectionManager, this is the sequence of calls that occurs after the component requests for a Connection:
ConnectionFactory.getConnection -> ConnectionManager.allocateConnection(ManagedConnectionFactory, ConnectionRequestInfo) -> ManagedConnectionFactory.createManagedConnection(Subject, ConnectionRequestInfo)

In the component-managed sign-on, the ConnectionFactory will just pass all data via the ConnectionRequestInfo, and IJ will pass that same data to the ManagedConnectionFactory, so there is nothing to do.
Elytron integration will be used for the second scenario, the container-managed sign-on. We need to create and provide the Subject to the ManagedConnectionFactory after ConnectionFactory is invoked.

There is also the scenario where ConnectionManager gets a connection already existent, but that doesn't affect us because in the end, we always end up in the getSubject method of AbstractionConnectionManager:
https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/org/jboss/jca/core/connectionmanager/AbstractConnectionManager.java#L1012

That method uses a SecurityFactory, which is part of the spi. There is an implementation of that interface for PicketBox, so I'm thinking that, at a first moment, is just a matter of implementing that spi for Elytron.
Related classes:
https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/org/jboss/jca/core/spi/security/SubjectFactory.java
https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/org/jboss/jca/core/security/DefaultSubjectFactory.java
https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/org/jboss/jca/core/security/picketbox/PicketBoxSubjectFactory.java

[Stefano Maestri]

Answer inline

On Friday, October 7, 2016 at 5:38:52 PM UTC+2, Flavia Rainone wrote:

Hi everyone.

So, I'm kicking off the thread for discussing the integration with Elytron.

Good.

 

As we have the new branch and the old branches, I decided we could move on to looking the new branch, that currently has no security code (correct me if I'm wrong, Stefano) after we have seen how to integrate branch 1.3.

Well there is already something about security in 2.0. See this thread on the forum and linked issues/PRs for details 

https://groups.google.com/forum/#!topic/ironjacamar-developers/hqBrT2nWjH0

 

The security in IronJacamar concerns two main parts, one is the Resource Principal related stuff, in short we need to apply a sequence of rules as defined by the spec to provide a secure access to the EIS, regardless of whether the application server is responsible for authenticating or the EIS itself.

correct 

Another important part is the Security Inflow, that I will discuss in another thread.

ok

Well we should check (but lower priority atm) scenarios w/ unified security in 2.x because they are slightly different

 

regards

S.

[Flavia Rainone]

I've taken another look at the code, and, given we will need to implement ElytronSubjectFactory, work will be needed in the following spots:
- the implementation itself. The current suggestion is that there will be an interceptor that will transform Elytron data into a JAAS Subject, and the SubjectFactory implementation will use that to provide the subject
- AbstractResourceAdapterDeploymentService.getSubjectFactory will need to identify whether to return PicketBoxSubjectFactory, whether to return ElytronSubjectFactory. I'm assuming we will use the same mapping used for that purpose in EJB, and for that reason, we will probably have that piece of code in a subclass in Wildfly.

Any thoughts?

[Stefano Maestri]

Yup right. Also AbstractDatasourceService.getSubjectFactory will need that. Note we are using Service injection for this.

 

HTH

regards

S. 

[sgui...@redhat.com]

On Thursday, November 17, 2016 at 3:40:08 AM UTC-2, Flavia Rainone wrote:
> I've taken another look at the code, and, given we will need to implement ElytronSubjectFactory, work will be needed in the following spots:
> - the implementation itself. The current suggestion is that there will be an interceptor that will transform Elytron data into a JAAS Subject, and the SubjectFactory implementation will use that to provide the subject

We are currently working on an utility class to convert Elytron SecurityIdentities to Subject instances. So it looks like the IJ SubjectFactory implementation will internally use this utility. If we take an Elytron security domain name we can fetch the domain from its respective service and use it to obtain the current authenticated identity. This identity can then be passed to the utility class to obtain the corresponding Subject.

> - AbstractResourceAdapterDeploymentService.getSubjectFactory will need to identify whether to return PicketBoxSubjectFactory, whether to return ElytronSubjectFactory. I'm assuming we will use the same mapping used for that purpose in EJB, and for that reason, we will probably have that piece of code in a subclass in Wildfly.

Yeah, if you determine the name of the security domain via deployment descriptor then we should probably go for the same config that was added in the EJB and Undertow subsystems - a mapping from the deployment security domain to the elytron security domain. If such mapping exists, the factory will return an instance of ElytronSubjectFactory. Otherwise, the legacy PicketBoxSubjectFactory is returned.

>
> Any thoughts?

[sgui...@redhat.com]

The wiring shouldn't change much as the Elytron domains are exposed as capabilities.

>  
> HTH
>
>
> regards
> S. 

[Flavia Rainone]

The current code for Security integration is here:
https://github.com/fl4via/wildfly/commits/ij-elytron

And here:
https://github.com/fl4via/ironjacamar/commits/elytron

We need to discuss two things in this regard:
1. Differentiating PicketBox from Elytron security domains
   Currently, the solution in the code was to add a new attribute elytron-security-domain. Does this sound reasonable?
2. What are we going to provide as a SubjectFactory in AS. It appears that Elytron team's plan rules out the idea of having a SubjectFactory in AS? We need more information as this part is key as is the main part missing in the code.

[Flavia Rainone]

Oh, yeah, another observation: the code is now based on the 1.4 branch, the most current one in the 1.x series.