[wildfly-dev] How to set an authorized identity to EltyronSecurity Context
Pedro Igor Silva
psilva at redhat.com
Thu Jun 7 07:47:08 EDT 2018
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 <ema at redhat.com> 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.
>
> [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.ht
>>>>>> ml#getPublicCredentials--
>>>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-
>>>>>> javadoc/org/wildfly/security/auth/server/SecurityIdentity.ht
>>>>>> ml#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/wildfly/tree/master/webservices/s
>>>>>>> erver-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/20180607/17739979/attachment-0001.html
More information about the wildfly-dev
mailing list