[keycloak-dev] Adapters

Stian Thorgersen stian at redhat.com
Wed Sep 17 03:07:25 EDT 2014



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 16 September, 2014 3:54:50 PM
> Subject: Re: [keycloak-dev] Adapters
> 
> 
> 
> On 9/16/2014 9:15 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 16 September, 2014 3:10:20 PM
> >> Subject: Re: [keycloak-dev] Adapters
> >>
> >> I disagree.  We need to expand our adapters everywhere.  Tomcat, Jetty,
> >> node.js, Rails, etc.  Pure servlet, pure Java, pure openid connect
> >> libraries are only a fallback plan.
> >
> > Who is going to implement and maintain all those adapters? I just can't see
> > us having enough man-power to do that. Especially if we start venturing
> > into non-java land.
> >
> 
> You're starting to sound like a whiny product manager instead of
> somebody that wants a successful keycloak project. :)

You're wrong, I'm a whiny developer ;)

I give in, but we'll have to automate testing of all these adapters. I'm going to sink into depression if I have to manually test all of this for every release...

> 
> We're just going to have to do it.  Having an IAM that only works well
> in a JBoss ecosystem is unacceptable, IMO.  LIke I said, most of the
> logic in Java is in a common core adapter library already.  People are
> already demanding Tomcat support.  Netty won't be far behind.
> 
> These integration requirements are just going to become worse and worse.
>   We just have to deal with it if we want to succeed.
> 
> >>
> >> Also, we can't rely on third-party libs for the reasons I mentioned
> >> below.  Bearer auth is also implementation dependent because tokens are
> >> opaque in oauth/openid specs.  So any rest service is going to have to
> >> understand our token format and extract and validate the JWS.
> >
> > What parts of the token are non-standard other than the roles? OAuth2 has a
> > standard param for roles 'scope', couldn't we use that?
> >
> 
> 
> Token formats are not standardized at all, not even around JWT.  Go read
> oauth2/openid connect.  Access tokens (and codes) are completely opaque.
>   I even had a talk with somebody on Oauth-WG about this as I wanted to
> standardize our CORS stuff.  He told me that nobody will ever agree on
> the token format.  At least not at this point in time.  Also scope has
> nothing to do with roles.  Scope doesn't solve bearer auth token
> validation problem.

I thought there was a standard 'scope' param in the jwt, but looks like I'm wrong.

I might need to brush up on these specs, and now I'm also going to have to read about SAML

> 
> >>
> >>
> >>
> >> On 9/16/2014 7:59 AM, Stian Thorgersen wrote:
> >>> What I was hoping to be able to achieve was a pure Java adapter, with an
> >>> easy to use and well documented API. This would allow anyone to use
> >>> Keycloak from anything Java. Most of the code is there, but we can
> >>> clean-up the API IMO, and also provide some examples and documentation.
> >>>
> >>> Further, we'd provide a pure Servlet adapter. As you point out it can't
> >>> provide the same level of integration as our WildFly and AS7/EAP
> >>> adapters.
> >>> However, providing bespoke adapters for Tomcat, Jetty, etc. is going to
> >>> be
> >>> too much of an overhead, so I don't think we should provide bespoke
> >>> adapters for non Red Hat products.
> >>>
> >>> For mobile could just delegate to AeroGear. Ideally, AeroGear would
> >>> provide
> >>> the SDKs and documentation to use Keycloak with Android, iOS, Windows
> >>> Mobile, Firefox, etc. and we would just add references to AeroGear in our
> >>> documentation and webpage.
> >>>
> >>> For other programming languages (php, ruby, etc.) I'm less sure what we
> >>> can
> >>> achieve. Perhaps we can delegate to existing OpenID Connect client
> >>> libraries?
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Monday, 15 September, 2014 5:17:35 PM
> >>>> Subject: Re: [keycloak-dev] Adapters
> >>>>
> >>>> Much of you want is already the reality, but there are some caveats you
> >>>> must know about:
> >>>>
> >>>> * Adapters need specific integration with each app server as they need
> >>>> to extract and set role mappings prior to the servlet container's roles
> >>>> allowed checks.  This can't be done in a filter.
> >>>>
> >>>> * Being able to propagate the Subject between component layers
> >>>> (Servlet->EJB) requires specific app server integration.
> >>>>
> >>>> * A keycloak logout invokes on adapter's admin url to invalidate the
> >>>> HTTP session.  The HTTP session invalidation is app server specific.
> >>>>
> >>>> * I don't believe you can obtain client cert information from the
> >>>> servlet API which will be come important when we add client-cert support
> >>>>
> >>>> Wildfly and JBossWeb have different integration SPIs for security, but
> >>>> most of the adapter code lives in a common library whose only dependency
> >>>> is Apache HTTP Client.  The core adapter library has a tiny Http message
> >>>> and http session mgmt facde to bridge between the two different
> >>>> containers.
> >>>>
> >>>> On 9/15/2014 10:38 AM, Stian Thorgersen wrote:
> >>>>> I think it would make sense to provide a plain Java adapter, as well as
> >>>>> a
> >>>>> plain Servlet adapter. Further this should be the base for all other
> >>>>> adapters.
> >>>>>
> >>>>>      +--------+ +---------+  +-----------+     +---------+
> >>>>>      | Tomcat | |JBoss AS |  |PicketLink |     | WildFly |
> >>>>>      | Jetty  | |JBoss EAP|  |           |     |         |
> >>>>>      | ...    | |         |  |           |     |         |
> >>>>>      +----+---+ +---+-----+  +---+-------+     +----+----+
> >>>>>           |         |            |                  |
> >>>>>           |     +---v-----+      |             +----v----+
> >>>>>           +----->Servlet  <------+             | Undertow|
> >>>>>                 |         |                    |         |
> >>>>>                 +----+----+                    +----+----+
> >>>>>                      |       +---------+            |
> >>>>>                      +------->Java     <------------+
> >>>>>                              |         |
> >>>>>                              +---------+
> >>>>>
> >>>>> The Java adapter should have minimum dependencies (maybe only
> >>>>> http-client?).
> >>>>>
> >>>>> Don't get to hung-up with the syntax (I knocked this together in 2
> >>>>> min),
> >>>>> but the general idea would be something like:
> >>>>>
> >>>>>            InputStream is = new FileInputStream("keycloak.json");
> >>>>>
> >>>>>            KeycloakOAuthClient client = KeycloakClient.createOAuth(is);
> >>>>>
> >>>>>            // get login url
> >>>>>            URL loginUrl = client.createLoginUrl(redirectUri);
> >>>>>
> >>>>>            // exchange code to token
> >>>>>            AccessTokenResponse response = client.getToken(code,
> >>>>>            clientCredentials);
> >>>>>
> >>>>>            // refresh token
> >>>>>            client.refreshToken(response.getToken());
> >>>>>
> >>>>> We have most of the code, but what we don't is a public Java API.
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>> http://bill.burkecentral.com
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 


More information about the keycloak-dev mailing list