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(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: "Marek Posolda" <mposolda(a)redhat.com&gt;, keycloak-user(a)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(a)redhat.com&gt; >>>> To: "Marek Posolda" <mposolda(a)redhat.com&gt; >>>> Cc: keycloak-user(a)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-bind... >>>>>> 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(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>