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

Thu Nov 27 10:22:23 EST 2014

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