[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