On Wed, Apr 26, 2017 at 7:23 PM, Jonathan D'Andries < jonathandandries(a)gmail.com&gt; wrote: > Thank you Sebastien, > > This is SO close to a perfect solution. It appears that including > "Accept: application/json" header allows the service to determine if > bearer-only should be enabled based on well-known HTTP headers. > Unfortunately, it still doesn't let me call the services via swagger > without specifying the bearer-token explicitly. This is because swagger is > calling the service as if it were a machine (by including the Accept > header). In a perfect world, the auto-detect logic would allow me to use > swagger to call the services as if it were a web browser even though it's > including the headers that indicated it's a machine. My hope is that it > would detect an existing session state that provides > authentication/authorization info, and this would override the test for the > HTTP headers. > > Here is how I would like "autodetect-bearer-only" to behave: > - If you are accessing with a web browser and not specifying the > detected headers, it works perfectly as-is. In this case, the user is > redirected to a login page, and future access is authenticated with a > session cookie. However, > - If you are specifying the headers that indicate you are a machine > (even if still in a web browser session), then the service will only > authentication with the "Authentication: bearer ..." header. What I want is > for this option to respect the session state if it happens to exist. > > I'm worried that I may be asking for a code change in the way the > autodetect logic works. Instead of just looking for the typical headers > "X-Requested-With, SOAPAction or Accept," could it also check if the user > is already logged in with existing session state? > We have at least another use case where this would be needed (JSF app making Ajax requests) and where the session state should be honored inside a bearer-only request. So I think I will open a ticket for this specifically so we can start planning and discussing around this enhancement. Unfortunately until then I don't see a real workaround for this. > > > Is there a way to make this work? Or perhaps there is a reason this is a > bad idea? > > > Thanks, > > Jonathan > > > > On Wed, Apr 26, 2017 at 11:32 AM, Sebastien Blanc <sblanc(a)redhat.com&gt; > wrote: > >> Don't make your client "bearer-only" and instead in your config add : >> "autodetect-bearer-only" : true >> >> That should solve your issue. >> >> >> >> On Wed, Apr 26, 2017 at 6:13 PM, Jonathan D'Andries < >> jonathandandries(a)gmail.com&gt; wrote: >> >>> Here is what I want to do: >>> >>> I have built REST services in Spring Boot. For the services themselves, >>> I >>> want to use "bearer-only" access type so that applications are NOT >>> redirected to a login page if unauthenticated. >>> >>> However, I want the generated swagger documentation to use the >>> "confidential" access type so that swagger-ui.html redirects the >>> user/browser to a login page and capture the token that will then be >>> passed >>> to the services when testing things out. >>> >>> It seems like the best way to accomplish this is with two clients >>> similar >>> to the demo here: >>> >>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo >>> ak-securing.html >>> >>> My concern is that having two client configurations in my spring boot >>> application.yml doesn't seem possible - am I missing something? I am >>> aware >>> of the multi-tenant options for Keycloak, but I don't actually want two >>> different realms: >>> >>> https://keycloak.gitbooks.io/documentation/securing_apps/top >>> ics/oidc/java/multi-tenancy.html >>> >>> For whatever configuration I come up with, I want the user's token to >>> apply >>> to both the swagger-ui and the services, but with two different access >>> types. >>> >>> Here are some things I've learned so far: >>> >>> I'm aware that swagger-ui offers an option to authenticate it's services >>> with a token. There are two limitations of this approach: >>> 1. With springfox generated swagger, it doesn't seem to work. I'd have >>> to >>> put a lot of effort to fix this, and I'd rather not because >>> 2. You would still need to get a token from somewhere, and that means >>> pointing users to another login page that isn't automatically prompted >>> when >>> you go to swagger-ui. It just seems like a more annoying user >>> experience to >>> have to take extra steps to generate a token and then paste that into >>> swagger-ui. >>> >>> I'm also aware that my spring boot configuration can be more restrictive >>> than the keycloak client configuration. In other words, I can restrict >>> to >>> bearer-only in my service even if the client is configured for >>> confidential >>> access type. If there is a way for different values for >>> keycloak.bearer-only based on URL pattern in the >>> keycloak-spring-boot-adapter, this could be a real option. >>> >>> >>> Thanks for any help/advice you may have. >>> >>> Jonathan >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> >