How to set an authorized identity to EltyronSecurity Context

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

How to set an authorized identity to EltyronSecurity Context

Alessio Soldano
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Alessio Soldano

On Wed, May 30, 2018 at 11:27 AM, Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat




--

Alessio Soldano

Associate Manager

Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Darran Lofthouse-2
In reply to this post by Alessio Soldano
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Jim Ma
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Darran Lofthouse-2
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Jim Ma
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Darran Lofthouse-2
So the validation is within Apache CXF - is there an end result to this validation where you have access to everything you need where we could perform some additional steps?


On Thu, 31 May 2018 at 10:34 Jim Ma <[hidden email]> wrote:
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Jim Ma
On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
So the validation is within Apache CXF - is there an end result to this validation where you have access to everything you need where we could perform some additional steps?


 After Apache CXF validation, we can get a LoginContext from CXF's exchange message : https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
 Can we do something to convert it to an Elytron authenticated identity ?
 Or we have to hook/replace something with Elytron in CXF's validation to make this work ?


On Thu, 31 May 2018 at 10:34 Jim Ma <[hidden email]> wrote:
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Darran Lofthouse-2
Just added Pedro in CC so see if he has any suggestions - this is sounding similar to the problems he would have needed to handle when he added support for KeyCloak integration using the Elytron APIs.

Although the reported problem we are working on is in the context of access to the token it does currently sound that there is a missing pre-requisite step of tying the authentication to Elytron to we can populate a SecurityIdentity.  But this does not sound like the first time we have needed to approach this.

Regards,
Darran Lofthouse.


On Thu, 31 May 2018 at 10:54 Jim Ma <[hidden email]> wrote:
On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
So the validation is within Apache CXF - is there an end result to this validation where you have access to everything you need where we could perform some additional steps?


 After Apache CXF validation, we can get a LoginContext from CXF's exchange message : https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
 Can we do something to convert it to an Elytron authenticated identity ?
 Or we have to hook/replace something with Elytron in CXF's validation to make this work ?



On Thu, 31 May 2018 at 10:34 Jim Ma <[hidden email]> wrote:
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Pedro Igor Silva
In Keycloak integration we have a specific security realm implementation that expects a principal previously authenticated by a keycloak adapter (e.g.: using SAML or OIDC) and builds an authorized identity based on it. Basically, what this security realm does is populate the authorized idenitty with information from tokens.

Later we complete authentication in Elytron and set the token as a credential into the identity. It is worth mention that in Keycloak integration, the adapter is a Elytron HTTP Authentication Mechanism, so we don't deal directly with the security domain but with the callback handler.

Regarding ElytronSecurityDomainContextImpl, is method pushContext called after a call to isValid ? If so, the security domain should be set with the security identity and you don't even need to keep that ThreadLocal ...

On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse <[hidden email]> wrote:
Just added Pedro in CC so see if he has any suggestions - this is sounding similar to the problems he would have needed to handle when he added support for KeyCloak integration using the Elytron APIs.  

Although the reported problem we are working on is in the context of access to the token it does currently sound that there is a missing pre-requisite step of tying the authentication to Elytron to we can populate a SecurityIdentity.  But this does not sound like the first time we have needed to approach this. 

Regards,
Darran Lofthouse.


On Thu, 31 May 2018 at 10:54 Jim Ma <[hidden email]> wrote:
On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
So the validation is within Apache CXF - is there an end result to this validation where you have access to everything you need where we could perform some additional steps?


 After Apache CXF validation, we can get a LoginContext from CXF's exchange message : https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
 Can we do something to convert it to an Elytron authenticated identity ?
 Or we have to hook/replace something with Elytron in CXF's validation to make this work ?



On Thu, 31 May 2018 at 10:34 Jim Ma <[hidden email]> wrote:
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat






_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Alessio Soldano
Hi Pedro,
I'll let Jim follow-up on the details here and see with you the best way to move forward.
This said, in the current scenario, the isValid is method is not called (it was originally thought for the username token profile scenario, so the string password credential would be available, etc), maybe it should be changed a bit to be used in this scenario too, so that the pushContext is not needed, according to what you're writing below.
Can you and Jim please review the current implementation of ElytronSecurityDomainContextImpl and change it to support this SAML token authentication scenario too?
Thanks

On Mon, Jun 4, 2018 at 3:31 PM, Pedro Igor Silva <[hidden email]> wrote:
In Keycloak integration we have a specific security realm implementation that expects a principal previously authenticated by a keycloak adapter (e.g.: using SAML or OIDC) and builds an authorized identity based on it. Basically, what this security realm does is populate the authorized idenitty with information from tokens.

Later we complete authentication in Elytron and set the token as a credential into the identity. It is worth mention that in Keycloak integration, the adapter is a Elytron HTTP Authentication Mechanism, so we don't deal directly with the security domain but with the callback handler.

Regarding ElytronSecurityDomainContextImpl, is method pushContext called after a call to isValid ? If so, the security domain should be set with the security identity and you don't even need to keep that ThreadLocal ...


On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse <[hidden email]> wrote:
Just added Pedro in CC so see if he has any suggestions - this is sounding similar to the problems he would have needed to handle when he added support for KeyCloak integration using the Elytron APIs.  

Although the reported problem we are working on is in the context of access to the token it does currently sound that there is a missing pre-requisite step of tying the authentication to Elytron to we can populate a SecurityIdentity.  But this does not sound like the first time we have needed to approach this. 

Regards,
Darran Lofthouse.


On Thu, 31 May 2018 at 10:54 Jim Ma <[hidden email]> wrote:
On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
So the validation is within Apache CXF - is there an end result to this validation where you have access to everything you need where we could perform some additional steps?


 After Apache CXF validation, we can get a LoginContext from CXF's exchange message : https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
 Can we do something to convert it to an Elytron authenticated identity ?
 Or we have to hook/replace something with Elytron in CXF's validation to make this work ?



On Thu, 31 May 2018 at 10:34 Jim Ma <[hidden email]> wrote:
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat








--

Alessio Soldano

Associate Manager

Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Jim Ma
In reply to this post by Pedro Igor Silva
On 06/04/2018 09:31 PM, Pedro Igor Silva wrote:
In Keycloak integration we have a specific security realm implementation that expects a principal previously authenticated by a keycloak adapter (e.g.: using SAML or OIDC) and builds an authorized identity based on it. Basically, what this security realm does is populate the authorized idenitty with information from tokens.

Later we complete authentication in Elytron and set the token as a credential into the identity. It is worth mention that in Keycloak integration, the adapter is a Elytron HTTP Authentication Mechanism, so we don't deal directly with the security domain but with the callback handler.

Regarding ElytronSecurityDomainContextImpl, is method pushContext called after a call to isValid ? If so, the security domain should be set with the security identity and you don't even need to keep that ThreadLocal ...
 
 Thanks Pedro . Do you think the keycloak Elytron integration code can be improved or changed to a common utility to convert the principal to an Elytron identity?
 Can you please point me the integration code or some Elytron example code snippet to build this authorized identity from a authenticated principal ?    


On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse <[hidden email]> wrote:
Just added Pedro in CC so see if he has any suggestions - this is sounding similar to the problems he would have needed to handle when he added support for KeyCloak integration using the Elytron APIs.  

Although the reported problem we are working on is in the context of access to the token it does currently sound that there is a missing pre-requisite step of tying the authentication to Elytron to we can populate a SecurityIdentity.  But this does not sound like the first time we have needed to approach this. 

Regards,
Darran Lofthouse.


On Thu, 31 May 2018 at 10:54 Jim Ma <[hidden email]> wrote:
On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
So the validation is within Apache CXF - is there an end result to this validation where you have access to everything you need where we could perform some additional steps?


 After Apache CXF validation, we can get a LoginContext from CXF's exchange message : https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
 Can we do something to convert it to an Elytron authenticated identity ?
 Or we have to hook/replace something with Elytron in CXF's validation to make this work ?



On Thu, 31 May 2018 at 10:34 Jim Ma <[hidden email]> wrote:
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat







_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Darran Lofthouse-2
On the WildFly Elytron side if there is anything missing we can certainly consider it - I know on the KeyCloak side a KeyCloak specific realm was used but if we need something more generic for SAML we can certainly look at adding it if it is needed for this integration.

Regards,
Darran Lofthouse.


On Wed, 6 Jun 2018 at 06:30 Jim Ma <[hidden email]> wrote:
On 06/04/2018 09:31 PM, Pedro Igor Silva wrote:
In Keycloak integration we have a specific security realm implementation that expects a principal previously authenticated by a keycloak adapter (e.g.: using SAML or OIDC) and builds an authorized identity based on it. Basically, what this security realm does is populate the authorized idenitty with information from tokens.

Later we complete authentication in Elytron and set the token as a credential into the identity. It is worth mention that in Keycloak integration, the adapter is a Elytron HTTP Authentication Mechanism, so we don't deal directly with the security domain but with the callback handler.

Regarding ElytronSecurityDomainContextImpl, is method pushContext called after a call to isValid ? If so, the security domain should be set with the security identity and you don't even need to keep that ThreadLocal ...
 
 Thanks Pedro . Do you think the keycloak Elytron integration code can be improved or changed to a common utility to convert the principal to an Elytron identity?
 Can you please point me the integration code or some Elytron example code snippet to build this authorized identity from a authenticated principal ?    


On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse <[hidden email]> wrote:
Just added Pedro in CC so see if he has any suggestions - this is sounding similar to the problems he would have needed to handle when he added support for KeyCloak integration using the Elytron APIs.  

Although the reported problem we are working on is in the context of access to the token it does currently sound that there is a missing pre-requisite step of tying the authentication to Elytron to we can populate a SecurityIdentity.  But this does not sound like the first time we have needed to approach this. 

Regards,
Darran Lofthouse.


On Thu, 31 May 2018 at 10:54 Jim Ma <[hidden email]> wrote:
On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
So the validation is within Apache CXF - is there an end result to this validation where you have access to everything you need where we could perform some additional steps?


 After Apache CXF validation, we can get a LoginContext from CXF's exchange message : https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
 Can we do something to convert it to an Elytron authenticated identity ?
 Or we have to hook/replace something with Elytron in CXF's validation to make this work ?



On Thu, 31 May 2018 at 10:34 Jim Ma <[hidden email]> wrote:
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat







_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Pedro Igor Silva
In reply to this post by Jim Ma
I don't think Keycloak integration code can be worked to be a common utility.

It seems to me that you would need a specific security realm implementation from where you could just return an authorized identity as a result of parsing the SAML assertion. Here is what we have in Keycloak [1]. As you can see, we are basically trusting a KeycloakPrincipal, previously created by the keycloak adapter, and creating an authorization identity from it. We don't re-authenticate the user.

So when pushContext is called, you could use serverauthenticationcontext and the CBH to ask Elytron for a security identity. See [2]. In this last example, we pass the previously authenticated principal via EvidenceVerifyCallback.

I think this might work for you.


On Wed, Jun 6, 2018 at 12:30 AM, Jim Ma <[hidden email]> wrote:
On 06/04/2018 09:31 PM, Pedro Igor Silva wrote:
In Keycloak integration we have a specific security realm implementation that expects a principal previously authenticated by a keycloak adapter (e.g.: using SAML or OIDC) and builds an authorized identity based on it. Basically, what this security realm does is populate the authorized idenitty with information from tokens.

Later we complete authentication in Elytron and set the token as a credential into the identity. It is worth mention that in Keycloak integration, the adapter is a Elytron HTTP Authentication Mechanism, so we don't deal directly with the security domain but with the callback handler.

Regarding ElytronSecurityDomainContextImpl, is method pushContext called after a call to isValid ? If so, the security domain should be set with the security identity and you don't even need to keep that ThreadLocal ...
 
 Thanks Pedro . Do you think the keycloak Elytron integration code can be improved or changed to a common utility to convert the principal to an Elytron identity?
 Can you please point me the integration code or some Elytron example code snippet to build this authorized identity from a authenticated principal ?    


On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse <[hidden email]> wrote:
Just added Pedro in CC so see if he has any suggestions - this is sounding similar to the problems he would have needed to handle when he added support for KeyCloak integration using the Elytron APIs.  

Although the reported problem we are working on is in the context of access to the token it does currently sound that there is a missing pre-requisite step of tying the authentication to Elytron to we can populate a SecurityIdentity.  But this does not sound like the first time we have needed to approach this. 

Regards,
Darran Lofthouse.


On Thu, 31 May 2018 at 10:54 Jim Ma <[hidden email]> wrote:
On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
So the validation is within Apache CXF - is there an end result to this validation where you have access to everything you need where we could perform some additional steps?


 After Apache CXF validation, we can get a LoginContext from CXF's exchange message : https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
 Can we do something to convert it to an Elytron authenticated identity ?
 Or we have to hook/replace something with Elytron in CXF's validation to make this work ?



On Thu, 31 May 2018 at 10:34 Jim Ma <[hidden email]> wrote:
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat








_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Jim Ma
Just to understand. I saw the SecurityIdentiy will be called by KeycloakHttpServerAuthenticationMechanism, and this will finally trigger
the KeycloakSecurityRealm to create identity.   To make this all work, we need to
configure KeycloakSecurityRealm and KeycloakHttpServerAuthenticationMechanism under Elytron subsystem, right?

 
 06/07/2018 12:25 AM, Pedro Igor Silva wrote:
I don't think Keycloak integration code can be worked to be a common utility.

It seems to me that you would need a specific security realm implementation from where you could just return an authorized identity as a result of parsing the SAML assertion. Here is what we have in Keycloak [1]. As you can see, we are basically trusting a KeycloakPrincipal, previously created by the keycloak adapter, and creating an authorization identity from it. We don't re-authenticate the user.

So when pushContext is called, you could use serverauthenticationcontext and the CBH to ask Elytron for a security identity. See [2]. In this last example, we pass the previously authenticated principal via EvidenceVerifyCallback.
I think this might work for you.


On Wed, Jun 6, 2018 at 12:30 AM, Jim Ma <[hidden email]> wrote:
On 06/04/2018 09:31 PM, Pedro Igor Silva wrote:
In Keycloak integration we have a specific security realm implementation that expects a principal previously authenticated by a keycloak adapter (e.g.: using SAML or OIDC) and builds an authorized identity based on it. Basically, what this security realm does is populate the authorized idenitty with information from tokens.

Later we complete authentication in Elytron and set the token as a credential into the identity. It is worth mention that in Keycloak integration, the adapter is a Elytron HTTP Authentication Mechanism, so we don't deal directly with the security domain but with the callback handler.

Regarding ElytronSecurityDomainContextImpl, is method pushContext called after a call to isValid ? If so, the security domain should be set with the security identity and you don't even need to keep that ThreadLocal ...
 
 Thanks Pedro . Do you think the keycloak Elytron integration code can be improved or changed to a common utility to convert the principal to an Elytron identity?
 Can you please point me the integration code or some Elytron example code snippet to build this authorized identity from a authenticated principal ?    


On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse <[hidden email]> wrote:
Just added Pedro in CC so see if he has any suggestions - this is sounding similar to the problems he would have needed to handle when he added support for KeyCloak integration using the Elytron APIs.  

Although the reported problem we are working on is in the context of access to the token it does currently sound that there is a missing pre-requisite step of tying the authentication to Elytron to we can populate a SecurityIdentity.  But this does not sound like the first time we have needed to approach this. 

Regards,
Darran Lofthouse.


On Thu, 31 May 2018 at 10:54 Jim Ma <[hidden email]> wrote:
On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
So the validation is within Apache CXF - is there an end result to this validation where you have access to everything you need where we could perform some additional steps?


 After Apache CXF validation, we can get a LoginContext from CXF's exchange message : https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
 Can we do something to convert it to an Elytron authenticated identity ?
 Or we have to hook/replace something with Elytron in CXF's validation to make this work ?



On Thu, 31 May 2018 at 10:34 Jim Ma <[hidden email]> wrote:
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat









_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to set an authorized identity to EltyronSecurity Context

Pedro Igor Silva
Exactly. In addition to a security domain referencing the realm and a http-authentication-factory referencing the domain.

On Thu, Jun 7, 2018 at 6:17 AM, Jim Ma <[hidden email]> wrote:
Just to understand. I saw the SecurityIdentiy will be called by KeycloakHttpServerAuthenticationMechanism, and this will finally trigger
the KeycloakSecurityRealm to create identity.   To make this all work, we need to
configure KeycloakSecurityRealm and KeycloakHttpServerAuthenticationMechanism under Elytron subsystem, right?


 
 06/07/2018 12:25 AM, Pedro Igor Silva wrote:
I don't think Keycloak integration code can be worked to be a common utility.

It seems to me that you would need a specific security realm implementation from where you could just return an authorized identity as a result of parsing the SAML assertion. Here is what we have in Keycloak [1]. As you can see, we are basically trusting a KeycloakPrincipal, previously created by the keycloak adapter, and creating an authorization identity from it. We don't re-authenticate the user.

So when pushContext is called, you could use serverauthenticationcontext and the CBH to ask Elytron for a security identity. See [2]. In this last example, we pass the previously authenticated principal via EvidenceVerifyCallback.
I think this might work for you.


On Wed, Jun 6, 2018 at 12:30 AM, Jim Ma <[hidden email]> wrote:
On 06/04/2018 09:31 PM, Pedro Igor Silva wrote:
In Keycloak integration we have a specific security realm implementation that expects a principal previously authenticated by a keycloak adapter (e.g.: using SAML or OIDC) and builds an authorized identity based on it. Basically, what this security realm does is populate the authorized idenitty with information from tokens.

Later we complete authentication in Elytron and set the token as a credential into the identity. It is worth mention that in Keycloak integration, the adapter is a Elytron HTTP Authentication Mechanism, so we don't deal directly with the security domain but with the callback handler.

Regarding ElytronSecurityDomainContextImpl, is method pushContext called after a call to isValid ? If so, the security domain should be set with the security identity and you don't even need to keep that ThreadLocal ...
 
 Thanks Pedro . Do you think the keycloak Elytron integration code can be improved or changed to a common utility to convert the principal to an Elytron identity?
 Can you please point me the integration code or some Elytron example code snippet to build this authorized identity from a authenticated principal ?    


On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse <[hidden email]> wrote:
Just added Pedro in CC so see if he has any suggestions - this is sounding similar to the problems he would have needed to handle when he added support for KeyCloak integration using the Elytron APIs.  

Although the reported problem we are working on is in the context of access to the token it does currently sound that there is a missing pre-requisite step of tying the authentication to Elytron to we can populate a SecurityIdentity.  But this does not sound like the first time we have needed to approach this. 

Regards,
Darran Lofthouse.


On Thu, 31 May 2018 at 10:54 Jim Ma <[hidden email]> wrote:
On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
So the validation is within Apache CXF - is there an end result to this validation where you have access to everything you need where we could perform some additional steps?


 After Apache CXF validation, we can get a LoginContext from CXF's exchange message : https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
 Can we do something to convert it to an Elytron authenticated identity ?
 Or we have to hook/replace something with Elytron in CXF's validation to make this work ?



On Thu, 31 May 2018 at 10:34 Jim Ma <[hidden email]> wrote:
The saml validation is now Apache CXF's SAML functionality. We can't port the CXF's security to rely on
our Elytron.  

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
It sounds to me then that the place to start is within the SAML validation, this is effectively an authentication step so should be ported over to an Elytron based authentication - the end result of the authentication would then be the required SecurityIdentity to propagate from container to container.


On Thu, 31 May 2018 at 03:57 Jim Ma <[hidden email]> wrote:
On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
I am currently gathering together some information regarding how the JCA subsystem handles the requirement of populating a Subject for propagation into a resource adapter, however there is a general question about what is attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not accessed as a Subject instead it is accessed a SecurityIdentity the current SecurityIdentity can always be retrieved by calling the current SecurityDomain: -


The SecurityIdentity has some similarity with the Subject in that amongst other things it also contains a collection of public credentials and a collection of private credentials: -


So I think the very first question is has the SecurityIdentity been correctly populated with any delegated credentials?  If not that is going to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it be ported to make use of the Elytron authentication client APIs which amongst other things provide support for delegation from the current identity.

If we need to we can look at a conversion to a Subject but we are only doing that where it is really required.

  We don't have the SecurityIdentity populated, there is only principal and subject created by jbossws/CXF's saml validator.
  We need to convert the subject/principal to Elytron's SecurityIdentity or something else, then later on EJB subystem with Elytron
  security can retrieve this authenticated info without check it twice. So we'd like to know how can we convert a subject/principal
  to Elytron's SecurityIdentity and let Elytron know this is already authenticated and authorized.

Thanks,
Jim  



Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <[hidden email]> wrote:
As suggested by Darran, I'm forwarding the message below to the list on behalf of Jim.
The classes Jim is referring to are at https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <[hidden email]>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <[hidden email]>
Cc: Alessio Soldano <[hidden email]>


Hi Darran,

We are helping look at a customer issue which requires propagate the authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecurityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can retrieve this security without check this twice ?

Thanks,

Jim




--

Alessio Soldano

Associate Manager

Red Hat










_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev