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

Gary Brown gbrown at redhat.com
Mon Dec 1 08:31:28 EST 2014 

Ok thanks.

Regards
Gary

----- Original Message -----
> Merged
> 
> The role mappings where missing in the test as the app didn't have a scope
> mapping. I added full scope mappings for the app in
> https://github.com/keycloak/keycloak/commit/e069f303a4f42f80541a7c123cfe9920868e359b.
> 
> Thanks
> 
> ----- 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: Friday, 28 November, 2014 4:19:43 PM
> > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer
> > tokens
> > 
> > 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
> > > > >>>>>>>>>
> > > > >>
> > > > 
> > > > 
> > > 
> > 
>

More information about the keycloak-user mailing list