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

Marek Posolda mposolda at redhat.com
Thu Nov 27 09:27:13 EST 2014


Your patch allows to both bearer and basic in single application, so 
maybe just enable-basic-auth for database-service and then it can be 
accessed from both 'bearer' and 'basic' requests? No need to add another 
variant of database-service then?

For UI, it may be possible to create example like 
'customer-portal-basic-auth' or something like that, which will be same 
like customer-portal, but just access customers via 'Basic auth' 
request. Or maybe it's also possible to just extend existing example 
instead of adding new one (like just add new JSP page to existing 
example, which will access customers via basic request). Maybe add new 
example (customer-portal-basic-auth) is slightly better option..

Marek

On 27.11.2014 14:59, Gary Brown wrote:
> 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