8:30 p.m.
So ... I'm unclear about what would be the best way to
1. Use a Native/JavaFX application with its own Login screen and within
its own process. Bring up a browser is not the user experience I would want
to force on the user.
2. Use KeyCloak for authentication
3. After authentication, use KeyCloak to communicate with a
Bearer-token-secured RESTful backend service over HTTP/HTTPS or WebSockets
Is the better way to:
1. Implement a local ServerSocket within the Native/JavaFX application
to accept the KeyCloak Callback. This can be done with something like
Undertow and a tiny handler, so not too complex. However ... I would like a
code example showing how to convert the inbound HttpServletRequest (to the
Undertow server on localhost) from the KeyCloak to the Keycloak
AccessToken. Presumably, one would need to decorate each JaxRS Client call
to the restful webservice (using Bearer token access) with the KeyCloak
Access token as well. Since the JaxRS 2.x Client is the de-facto standard
from the current JavaEE distribution, it would be good to see an example of
how to tailor a ... KeyCloak JaxRS Client request filter, maybe?
I realize, from the example and the codebase, that 99% of the use cases
here are Web/JavaScript clients and maybe Smartphone apps, but it would be
really nice to have an example holding the scenario above, since it is
basically the way to make native applications or JavaFX clients integrate
properly (i.e. not sprouting a browser, which yields an inferior user
experience) with services protected by KeyCloak. Fair?
2017-07-25 9:52 GMT+02:00 Thomas Darimont <thomas.darimont(a)googlemail.com>:
Hi Bill,
that's nice to hear!
Is there already a JIRA issue for that? May I open a pull request and you
take it from there?
I think the TLS feature was a bit over ambitious - so never mind. The idea
was to optionally allow using
https for connections to 127.0.0.1 + allowing users to pass-in a custom
cert / trust store.
Note that using 127.0.0.1 instead of localhost might cause some
compatibility problems and should be mentioned in the migration guide.
E.g. users who already use the keycloak-installed adapter probably need to
adapt the allowed redirect
uri pattern in the client configuration in Keycloak (127.0.0.1 instead of
localhost).
Cheers,
Thomas
2017-07-25 0:21 GMT+02:00 Bill Burke <bburke(a)redhat.com>:
>
>
> On 7/18/17 9:42 AM, Thomas Darimont wrote:
> > - Add support for TLS (with custom certificates) for https:// with
> localhost
>
> Hey, I'm incorporating your changes, but one question I have is why do
> you need this?
>
> Bill
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj(a)jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+