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

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