[keycloak-dev] Authenticating Desktop Applications with Keycloak and the keycloak-installed adapter
Lennart Jörelid
lennart.jorelid at gmail.com
Thu Jan 4 17:25:28 EST 2018
Hello there,
So ... looking at your codebase, I assume/guess your strategy is:
1. Find the URLs required from the 2.4.1. Endpoints
<http://www.keycloak.org/docs/latest/securing_apps/index.html#endpoints>
section
of the Keycloak documentation
2. Read the ...
http://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint URL
as linked from the Keycloak documentation to find the required parameters
into each call? Or something else?
3. Synthesize your rest calls to KeyCloak manually?
This could work, but ... well ... I feel that these things should really be
part of a deliverable within keycloak itself, such as an artifact called
keycloak-java-client-3.4.2.Final.jar, with a simple-to-use specification.
(In fact, i assumed I was just missing where these deliverables were
implemented).
Questions regarding a Pure JavaSE Keycloak client implementation
Some questions to you folks on the lists, then:
1. A JavaSE client implementation should likely start by fetching the
metadata information from
/realms/{realm-name}/.well-known/openid-configuration as indicated
within the Keycloak documentation.
1. The JaxRS method called to serve the information seems to be
getWellKnown within the class RealmResource. True?
2. The object served seems to be
OIDCConfigurationRepresentation, rendered
as JSON within the response from the service call. True?
3. Hence ... the entity class is OIDCConfigurationRepresentation -
and entities which will be needed both at the server side and at
the client
side (after unmarshaller) could/should be implemented within a separate
maven project which can then be included both by the Keycloak Standalone
client and the Server. This would serve to minimize the unnecessary
dependency bloat on the client side.
2. The JaxRS Client proxy approach, as outlined by the RestEasy
documentation
<https://docs.jboss.org/resteasy/docs/3.0-beta-3/userguide/html/RESTEasy_Client_Framework.html>
is
a good idea to simplify creating typed and consistent clients. Essentially,
if the Server provides an annotated interface for the JaxRS services all
that good type information can be used in a simple manner on the client
side.
1. Currently, the restful services within the Keycloak codebase do
not implement an interface, which implies that the 2 latter lines of code
within the code snippet below does not work (the made-up
"OpenIdConfiguration" type must be an interface, implemented by
the restful
service). This is - however - really easy to do; simply extract the typed
interface of the RealmResource. I will supply a JIRA ticket for this.
2. Adding a JaxRS 2.x Client filter to auto-inject the Http headers
("Auth: Bearer .. ") into each request to the Keycloak-protected
service is
simple enough. Perhaps we could/should re-use parts of the code from the
Keycloak codebase here.
3. Creating an async timer which polls the refresh-token (i.e. the
/realms/{realm-name}/protocol/openid-connect/token endpoint) also seems
decently straightforward after getting the token as such.
1. I suggest using the standard ExecutorService and an asynchronously
called Task
ResteasyClient client = new ResteasyClientBuilder().build();
ResteasyWebTarget target =
client.target("http://theKeycloakServer/realms/realmname/.well-known/openid-configuration");
OpenIdConfiguration typedResponse = target.proxy(OpenIdConfiguration.class);
typedResponse.getWellKnown("hello world");
Question to you in the list: Is this already available within the Keycloak
codebase? If so -- where?
2018-01-04 7:56 GMT+01:00 Hendrik Ebbers <hendrik.ebbers at me.com>:
> Hi Lennart,
>
> here is a gist that does a manual login by doing a rest call to keycloak.
> By doing so you do not need any callback
>
> https://gist.github.com/hendrikebbers/4c14db0967ce14ce623baa1f698b230c
>
> Next to this you need to handle some other thinks like the refresh of the
> token on your own. This must be done in an additional request for example.
>
> Cheers,
>
> Hendrik
>
>
>
> Am 04.01.2018 um 03:30 schrieb Lennart Jörelid <lennart.jorelid at gmail.com
> >:
>
> 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 at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at 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 at jguru.se <lj at jguru.se>
> | URL: www.jguru.se
> | Phone
> | (skype): jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at 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 at jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
More information about the keycloak-dev
mailing list