[wildfly-dev] How to set an authorized identity to EltyronSecurity Context
Pedro Igor Silva
psilva at redhat.com
Wed Jun 6 12:25:52 EDT 2018
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.
[1]
https://github.com/pedroigor/keycloak/blob/d3e559453b7dcf6f0d9f32c5a9a7f8c49403bb3a/adapters/oidc/wildfly-elytron/src/main/java/org/keycloak/adapters/elytron/KeycloakSecurityRealm.java#L83
[2]
https://github.com/pedroigor/keycloak/blob/d3dee07956be8d0ac69466ac9367984ab0ea072d/adapters/oidc/wildfly-elytron/src/main/java/org/keycloak/adapters/elytron/SecurityIdentityUtil.java#L45
On Wed, Jun 6, 2018 at 12:30 AM, Jim Ma <ema at redhat.com> 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 <
> 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> 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/Login
>>> SecurityContext.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> 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> 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#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#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>
>>>>> 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/wil
>>>>>> dfly/tree/master/webservices/server-integration/src/main/
>>>>>> java/org/jboss/as/webservices/security
>>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Jim Ma <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>
>>>>>> Cc: Alessio Soldano <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(getSecur
>>>>>> ityDomain());
>>>>>> 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/53764d24/attachment-0001.html
More information about the wildfly-dev
mailing list