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?

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.

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

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

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

Another thing is that we should add an example + documentation for this feature.

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

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

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

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

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

I think in the long run if we try to show all features in the demo it'll end up getting to bloated. It's probably best to keep the demo to the core features (SSO, etc) and have separate basic examples (quickstarts?) for the rest. ----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Gary Brown" <gbrown(a)redhat.com&gt; > Cc: "Stian Thorgersen" <stian(a)redhat.com&gt;, keycloak-user(a)lists.jboss.org > Sent: Thursday, 27 November, 2014 4:22:23 PM > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer > tokens > > 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(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 > >>>>>>>>> > >> > >

Merged The role mappings where missing in the test as the app didn't have a scope mapping. I added full scope mappings for the app in https://github.com/keycloak/keycloak/commit/e069f303a4f42f80541a7c123cfe9.... Thanks ----- 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: Friday, 28 November, 2014 4:19:43 PM > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer > tokens > > Hi Stian and Marek > > PR submitted: https://github.com/keycloak/keycloak/pull/874 > > I've added a comment to the jira > (https://issues.jboss.org/browse/KEYCLOAK-861) about roles - if whoever > reviews the PR could let me know. > > Thanks. > > Regards > Gary > > ----- Original Message ----- > > I think in the long run if we try to show all features in the demo it'll > > end > > up getting to bloated. It's probably best to keep the demo to the core > > features (SSO, etc) and have separate basic examples (quickstarts?) for > > the > > rest. > > > > ----- Original Message ----- > > > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > > > To: "Gary Brown" <gbrown(a)redhat.com&gt; > > > Cc: "Stian Thorgersen" <stian(a)redhat.com&gt;, > > > keycloak-user(a)lists.jboss.org > > > Sent: Thursday, 27 November, 2014 4:22:23 PM > > > Subject: Re: [keycloak-user] REST services supporting basic auth and > > > bearer > > > tokens > > > > > > 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(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 > > > >>>>>>>>> > > > >> > > > > > > > > >