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

[Gary Brown]

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