[keycloak-dev] Adapters

[Stian Thorgersen]

----- 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.

> 
> 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?

> 
> 
> 
> 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
>