[wildfly-dev] How to set an authorized identity to EltyronSecurity Context

Jim Ma ema at redhat.com
Tue Jun 5 23:30:09 EDT 2018


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 
> <darran.lofthouse at redhat.com <mailto:darran.lofthouse at redhat.com>> 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 <ema at redhat.com
>     <mailto:ema at redhat.com>> 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
>         <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 <ema at redhat.com
>>         <mailto:ema at redhat.com>> 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 <ema at redhat.com
>>>             <mailto:ema at redhat.com>> 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: -
>>>>
>>>>                 http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent--
>>>>                 <http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent-->
>>>>                 http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity--
>>>>                 <http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity-->
>>>>
>>>>                 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: -
>>>>
>>>>                 http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials--
>>>>                 <http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials-->
>>>>                 http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials--
>>>>                 <http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials-->
>>>>
>>>>                 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
>>>>                 <asoldano at redhat.com <mailto:asoldano at redhat.com>>
>>>>                 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
>>>>                     <https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security>
>>>>
>>>>
>>>>
>>>>                     ---------- Forwarded message ----------
>>>>                     From: *Jim Ma* <ema at redhat.com
>>>>                     <mailto:ema at redhat.com>>
>>>>                     Date: Wed, May 30, 2018 at 9:03 AM
>>>>                     Subject: Set an authorized identity to
>>>>                     EltyronSecurity Context
>>>>                     To: Darran Lofthouse
>>>>                     <darran.lofthouse at redhat.com
>>>>                     <mailto:darran.lofthouse at redhat.com>>
>>>>                     Cc: Alessio Soldano <asoldano at redhat.com
>>>>                     <mailto:asoldano at redhat.com>>
>>>>
>>>>
>>>>                     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
>>>>
>>>>                     <https://www.redhat.com>
>>>>
>>>>                     <https://red.ht/sig>
>>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180606/f448d45b/attachment-0001.html 


More information about the wildfly-dev mailing list