[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