[keycloak-user] REST services supporting basic auth and bearer tokens

Fri Nov 28 10:19:43 EST 2014

Hi Stian and Marek

PR submitted: https://github.com/keycloak/keycloak/pull/874

I've added a comment to the jira (https://issues.jboss.org/browse/KEYCLOAK-861) about roles - if whoever reviews the PR could let me know.

Thanks.

Regards
Gary

----- Original Message -----
> I think in the long run if we try to show all features in the demo it'll end
> up getting to bloated. It's probably best to keep the demo to the core
> features (SSO, etc) and have separate basic examples (quickstarts?) for the
> rest.
> 
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Gary Brown" <gbrown at redhat.com>
> > Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-user at lists.jboss.org
> > Sent: Thursday, 27 November, 2014 4:22:23 PM
> > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer
> > tokens
> > 
> > Oki, sounds good to me.
> > 
> > Marek
> > 
> > On 27.11.2014 15:37, Gary Brown wrote:
> > > Hi Marek
> > >
> > > I was originally thinking the same - but it would complicate the demo
> > > more.
> > >
> > > Its possible that the database-service could simply be changed to support
> > > both bearer and basic auth, and then provide curl instructions to
> > > demonstrate basic auth access, but then there wouldn't be an example
> > > showing a bearer-only configuration.
> > >
> > > So assuming that a 'bearer-only' example is still required, then having a
> > > completely independent basic auth example may be the next best thing -
> > > and
> > > then leave it as an exercise for the user to enable basic auth on the
> > > database-service?
> > >
> > > Regards
> > > Gary
> > >
> > > ----- Original Message -----
> > >> Sent previous email before I figured that you guys already decide on
> > >> something, so feel free to ignore me:-)
> > >>
> > >> On the other hand, it may be nice to show in the example that particular
> > >> jaxrs endpoint is able to support both bearer and basic auth in same
> > >> application imo.
> > >>
> > >> Marek
> > >>
> > >> On 27.11.2014 15:26, Gary Brown wrote:
> > >>> Ok sounds good.
> > >>>
> > >>> ----- Original Message -----
> > >>>> Another option is to add a separate basic example outside of the demo,
> > >>>> like
> > >>>> what was done for multi-tenancy. A single jax-rs endpoint that
> > >>>> supports
> > >>>> basic auth and an example curl command to invoke it?
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "Gary Brown" <gbrown at redhat.com>
> > >>>>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>>>> Cc: "Marek Posolda" <mposolda at redhat.com>,
> > >>>>> keycloak-user at lists.jboss.org
> > >>>>> Sent: Thursday, 27 November, 2014 2:59:46 PM
> > >>>>> Subject: Re: [keycloak-user] REST services supporting basic auth and
> > >>>>> bearer
> > >>>>> tokens
> > >>>>>
> > >>>>> In terms of example, was thinking the database-service is ideal -
> > >>>>> however
> > >>>>> I'm
> > >>>>> guessing it also needs to be shown as a 'bearer-only' example (as
> > >>>>> now).
> > >>>>>
> > >>>>> In the same way that there is multiple customer-apps, one approach
> > >>>>> could
> > >>>>> be
> > >>>>> to have an alternate database-service supporting basic auth as well,
> > >>>>> but
> > >>>>> then would also need a separate copy of the testrealm.json.
> > >>>>>
> > >>>>> Thoughts?
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> Great, if you do a PR include an example we can merge it before a
> > >>>>>> 1.1.0.Beta2
> > >>>>>> release (probably next week)
> > >>>>>>
> > >>>>>> ----- Original Message -----
> > >>>>>>> From: "Gary Brown" <gbrown at redhat.com>
> > >>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>>>>>> Cc: "Marek Posolda" <mposolda at redhat.com>,
> > >>>>>>> keycloak-user at lists.jboss.org
> > >>>>>>> Sent: Thursday, 27 November, 2014 1:48:55 PM
> > >>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth
> > >>>>>>> and
> > >>>>>>> bearer
> > >>>>>>> tokens
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> ----- Original Message -----
> > >>>>>>>> Looks good to me, but I'd like it to be an optional feature that
> > >>>>>>>> is
> > >>>>>>>> enabled
> > >>>>>>>> in keycloak.json (should be disabled by default).
> > >>>>>>> Sounds reasonable - I'll call the property 'enableBasicAuth'.
> > >>>>>>>
> > >>>>>>>> Another thing is that we should add an example + documentation for
> > >>>>>>>> this
> > >>>>>>>> feature.
> > >>>>>>> Will do.
> > >>>>>>>
> > >>>>>>>> ----- Original Message -----
> > >>>>>>>>> From: "Gary Brown" <gbrown at redhat.com>
> > >>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>
> > >>>>>>>>> Cc: keycloak-user at lists.jboss.org
> > >>>>>>>>> Sent: Thursday, 27 November, 2014 10:58:21 AM
> > >>>>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth
> > >>>>>>>>> and
> > >>>>>>>>> bearer
> > >>>>>>>>> tokens
> > >>>>>>>>>
> > >>>>>>>>> Hi Marek
> > >>>>>>>>>
> > >>>>>>>>> ----- Original Message -----
> > >>>>>>>>>> Hi,
> > >>>>>>>>>>
> > >>>>>>>>>> I am not 100% sure if having basic auth with direct grant
> > >>>>>>>>>> directly
> > >>>>>>>>>> in
> > >>>>>>>>>> our adapters is way to go. Probably yes as for your use-case it
> > >>>>>>>>>> makes
> > >>>>>>>>>> sense, so I am slightly for push your change as PR. But maybe
> > >>>>>>>>>> others
> > >>>>>>>>>> from team have different opinion.
> > >>>>>>>>>>
> > >>>>>>>>>> Earlier this week I've added DirectAccessGrantsLoginModule to KC
> > >>>>>>>>>> codebase, which is quite similar and is intended to be used for
> > >>>>>>>>>> non-web
> > >>>>>>>>>> applications (like SSH), which rely on JAAS. But I guess that
> > >>>>>>>>>> using
> > >>>>>>>>>> this
> > >>>>>>>>>> one is not good option for you as you want support for Basic and
> > >>>>>>>>>> Bearer
> > >>>>>>>>>> authentication in same web application, right?
> > >>>>>>>>> Thats correct.
> > >>>>>>>>>
> > >>>>>>>>>> Few more minor points to your changes:
> > >>>>>>>>>> - Is it possible to use net.iharder.Base64 instead of
> > >>>>>>>>>> org.apache.commons.codec.binary.Base64? Whole KC code has
> > >>>>>>>>>> dependency
> > >>>>>>>>>> on
> > >>>>>>>>>> net.iharder, so would be likely better to use this one to avoid
> > >>>>>>>>>> possible
> > >>>>>>>>>> dependency issues in adapters.
> > >>>>>>>>> That shouldn't be a problem.
> > >>>>>>>>>
> > >>>>>>>>>> - Wonder if it's possible to simplify a bit, like have single
> > >>>>>>>>>> "completeAuthentication" method for both bearer and basic
> > >>>>>>>>>> authenticator
> > >>>>>>>>>> (afaik only difference among them is different authMethod
> > >>>>>>>>>> right?).
> > >>>>>>>>>> But
> > >>>>>>>>>> this is really minor.
> > >>>>>>>>> Will do.
> > >>>>>>>>>
> > >>>>>>>>> I'll wait until mid next week before doing any more on this, to
> > >>>>>>>>> see
> > >>>>>>>>> whether
> > >>>>>>>>> others have an opinion.
> > >>>>>>>>>
> > >>>>>>>>> If the PR was accepted, any chance it could go into 1.1 even
> > >>>>>>>>> though
> > >>>>>>>>> in
> > >>>>>>>>> beta?
> > >>>>>>>>> If no, any idea what the timescale is for 1.2.beta1?
> > >>>>>>>>>
> > >>>>>>>>> Thanks for your feedback.
> > >>>>>>>>>
> > >>>>>>>>> Regards
> > >>>>>>>>> Gary
> > >>>>>>>>>
> > >>>>>>>>>> Marek
> > >>>>>>>>>>
> > >>>>>>>>>> On 26.11.2014 14:54, Gary Brown wrote:
> > >>>>>>>>>>> Hi
> > >>>>>>>>>>>
> > >>>>>>>>>>> Concrete use case - we have implemented the OASIS S-RAMP
> > >>>>>>>>>>> specification,
> > >>>>>>>>>>> in
> > >>>>>>>>>>> which it requires basic auth support
> > >>>>>>>>>>> (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html
> > >>>>>>>>>>> section 5 "The S-RAMP Specification does not attempt to define
> > >>>>>>>>>>> a
> > >>>>>>>>>>> security
> > >>>>>>>>>>> model for products that implement it.  For the Atom Binding,
> > >>>>>>>>>>> the
> > >>>>>>>>>>> only
> > >>>>>>>>>>> security requirement is that at a minimum, client and server
> > >>>>>>>>>>> implementations MUST be capable of being configured to use HTTP
> > >>>>>>>>>>> Basic
> > >>>>>>>>>>> Authentication in conjunction with a connection made with
> > >>>>>>>>>>> TLS.").
> > >>>>>>>>>>>
> > >>>>>>>>>>> However we also need the same service to support bearer token,
> > >>>>>>>>>>> for
> > >>>>>>>>>>> use
> > >>>>>>>>>>> within our KeyCloak SSO session.
> > >>>>>>>>>>>
> > >>>>>>>>>>> I've implemented a possible solution, details defined on
> > >>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-861.
> > >>>>>>>>>>>
> > >>>>>>>>>>> If this solution is on the right path, I would appreciate any
> > >>>>>>>>>>> feedback
> > >>>>>>>>>>> on
> > >>>>>>>>>>> any changes that might be required before submitting a PR.
> > >>>>>>>>>>> Currently
> > >>>>>>>>>>> there
> > >>>>>>>>>>> are no tests, but would aim to provide some with the PR.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Regards
> > >>>>>>>>>>> Gary
> > >>>>>>>>>>> _______________________________________________
> > >>>>>>>>>>> keycloak-user mailing list
> > >>>>>>>>>>> keycloak-user at lists.jboss.org
> > >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>>>>>>>> _______________________________________________
> > >>>>>>>>> keycloak-user mailing list
> > >>>>>>>>> keycloak-user at lists.jboss.org
> > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>>>>>>>>
> > >>
> > 
> > 
> 