3:42 p.m.
Hello folks,
I played a bit with the undocumented? [0] keycloak-installed adapter [1]
for integrating
desktop applications with Keycloak SSO and found some issues with it, which
I'd like to share.
Small explanation for those who are reading the list but don't know the
adapter... [2]
First some general notes / suggestions:
Is the keycloak-installed adapter something that will stay in keycloak or
was this just a PoC?
In the former case I think there are some things that could be improved or
extended a bit:
- Allow users to customize the locale used for the login pages opened by
the adapter
- Provide customizable response templates (perhaps by leveraging a provided
ResourceBundle)
- Allow to customize pages shown after login / logout served by the
keycloak-installed adapter
- Add support for TLS (with custom certificates) for https:// with localhost
I noticed that some browsers (e.g. Chrome) show an error page when trying
to
redirect to the local mini-webserver after a successful login since the
mini-webserver
(...server-socket) embedded in the adapter doesn't respond with a valid
HTTP response.
With that fixed, it worked with all browsers I tested (IE, Firefox, Chrome).
My current modifications of the keycloak-installed adapter
(with HTTP response fixes and response customizations) are here:
https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5...
An extended example (using the the modified keycloak-installed adapter) can
be found here:
https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
WDYT?
Cheers,
Thomas
[0] Not mentioned here:
https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java...
[1] https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed
[2] For those that haven't seen the adapter yet, it allows to authenticate
against Keycloak
from a desktop app (e.g. swing, javafx) by opening a desktop browser window
where a user
uses the regular keycloak login pages to login.
The trick is now that login page is opened with redirect URL that points to
a small local
"web server" (server-socket) on a free ephemeral port which is started by
the adapter.
After logging in the mini web-server receives performs the authenorization
code flow and eventually receives the tokens (access_token, refresh_token,
id_token) which can then be
used to call backend services from the client or retrieve new tokens
A nice side effect of this is, that the desktop application never sees a
users
password and one can leverage existing SSO sessions.
Btw. the google cloud cli uses the same approach to authenticate with gcp.
The Keycloak repo contains a small example for this:
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/c...
4:31 p.m.
I'm working on something for command line apps. A command-line
text/plain protocol so that login can happen within a console. I really
think keycloak-installation or the OAuth device flow is really poor
solution.
On 7/18/17 9:42 AM, Thomas Darimont wrote:
Hello folks,
I played a bit with the undocumented? [0] keycloak-installed adapter [1]
for integrating
desktop applications with Keycloak SSO and found some issues with it, which
I'd like to share.
Small explanation for those who are reading the list but don't know the
adapter... [2]
First some general notes / suggestions:
Is the keycloak-installed adapter something that will stay in keycloak or
was this just a PoC?
In the former case I think there are some things that could be improved or
extended a bit:
- Allow users to customize the locale used for the login pages opened by
the adapter
- Provide customizable response templates (perhaps by leveraging a provided
ResourceBundle)
- Allow to customize pages shown after login / logout served by the
keycloak-installed adapter
- Add support for TLS (with custom certificates) for https:// with localhost
I noticed that some browsers (e.g. Chrome) show an error page when trying
to
redirect to the local mini-webserver after a successful login since the
mini-webserver
(...server-socket) embedded in the adapter doesn't respond with a valid
HTTP response.
With that fixed, it worked with all browsers I tested (IE, Firefox, Chrome).
My current modifications of the keycloak-installed adapter
(with HTTP response fixes and response customizations) are here:
https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5...
An extended example (using the the modified keycloak-installed adapter) can
be found here:
https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
WDYT?
Cheers,
Thomas
[0] Not mentioned here:
https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java...
[1] https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed
[2] For those that haven't seen the adapter yet, it allows to authenticate
against Keycloak
from a desktop app (e.g. swing, javafx) by opening a desktop browser window
where a user
uses the regular keycloak login pages to login.
The trick is now that login page is opened with redirect URL that points to
a small local
"web server" (server-socket) on a free ephemeral port which is started by
the adapter.
After logging in the mini web-server receives performs the authenorization
code flow and eventually receives the tokens (access_token, refresh_token,
id_token) which can then be
used to call backend services from the client or retrieve new tokens
A nice side effect of this is, that the desktop application never sees a
users
password and one can leverage existing SSO sessions.
Btw. the google cloud cli uses the same approach to authenticate with gcp.
The Keycloak repo contains a small example for this:
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/c...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:04 p.m.
That's interesting.
Will there also be support for desktop apps in some way?
What in particular do you think is the problem with the approach used by
the keycloak-installed adapter
and OAuth device flow, guessing you mean:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 ?
Cheers,
Thomas
2017-07-19 16:31 GMT+02:00 Bill Burke <bburke(a)redhat.com>:
I'm working on something for command line apps. A command-line
text/plain protocol so that login can happen within a console. I really
think keycloak-installation or the OAuth device flow is really poor
solution.
On 7/18/17 9:42 AM, Thomas Darimont wrote:
> Hello folks,
>
> I played a bit with the undocumented? [0] keycloak-installed adapter [1]
> for integrating
> desktop applications with Keycloak SSO and found some issues with it,
which
> I'd like to share.
> Small explanation for those who are reading the list but don't know the
> adapter... [2]
>
> First some general notes / suggestions:
> Is the keycloak-installed adapter something that will stay in keycloak or
> was this just a PoC?
> In the former case I think there are some things that could be improved
or
> extended a bit:
>
> - Allow users to customize the locale used for the login pages opened by
> the adapter
> - Provide customizable response templates (perhaps by leveraging a
provided
> ResourceBundle)
> - Allow to customize pages shown after login / logout served by the
> keycloak-installed adapter
> - Add support for TLS (with custom certificates) for https:// with
localhost
>
> I noticed that some browsers (e.g. Chrome) show an error page when trying
> to
> redirect to the local mini-webserver after a successful login since the
> mini-webserver
> (...server-socket) embedded in the adapter doesn't respond with a valid
> HTTP response.
> With that fixed, it worked with all browsers I tested (IE, Firefox,
Chrome).
>
> My current modifications of the keycloak-installed adapter
> (with HTTP response fixes and response customizations) are here:
> https://github.com/thomasdarimont/keycloak/commit/
b8ee52a946e73503b1737f5ca7d4520b8484dae8
>
> An extended example (using the the modified keycloak-installed adapter)
can
> be found here:
> https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
>
> WDYT?
>
> Cheers,
> Thomas
>
> [0] Not mentioned here:
> https://keycloak.gitbooks.io/documentation/securing_apps/
topics/oidc/java/java-adapters.html
>
> [1] https://github.com/keycloak/keycloak/tree/master/adapters/
oidc/installed
>
> [2] For those that haven't seen the adapter yet, it allows to
authenticate
> against Keycloak
> from a desktop app (e.g. swing, javafx) by opening a desktop browser
window
> where a user
> uses the regular keycloak login pages to login.
> The trick is now that login page is opened with redirect URL that points
to
> a small local
> "web server" (server-socket) on a free ephemeral port which is started by
> the adapter.
>
> After logging in the mini web-server receives performs the
authenorization
> code flow and eventually receives the tokens (access_token,
refresh_token,
> id_token) which can then be
> used to call backend services from the client or retrieve new tokens
>
> A nice side effect of this is, that the desktop application never sees a
> users
> password and one can leverage existing SSO sessions.
> Btw. the google cloud cli uses the same approach to authenticate with
gcp.
>
> The Keycloak repo contains a small example for this:
> https://github.com/keycloak/keycloak/blob/master/examples/
demo-template/customer-app-cli/src/main/java/org/
keycloak/example/CustomerCli.java
> _______________________________________________
> 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
3:22 p.m.
some more food for thought:
Google seems to recommend using the Loopback IP address to obtain the
authorization
code from a successful Oauth 2.0 interaction in the browser, see [0].
Create authorization credentials -> Option 2: Loopback IP address (macOS,
Linux, Windows desktop)
Other methods like "manual copy/paste" (of the auth code) or "Programmatic
extraction"
are supported but not recommended - the recommended approach is to use
either
Loopback IP address or a Custom URI scheme (on mobile apps or Windows UWP).
Though, one might still be able to programmatically register a custom
protocol handler
in windows and other platforms.
Google also provides some example applications that demonstate the various
approaches.
Further more, OAuth for Apps: Sample Desktop Application for Windows [1]
mentions: OAuth 2.0 for Native Apps (draft-ietf-oauth-native-apps-12) [2]
which descibes the
approaches mentioned above in more detail.
E.g. in 4.1 "Authorization Flow for Native Apps Using the Browser" they
IMHO
describe the interaction model of the keycloak-installed adapter.
[0] https://developers.google.com/identity/protocols/OAuth2InstalledApp
[1]
https://github.com/googlesamples/oauth-apps-for-windows/tree/master/OAuth...
[2] https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12
2017-07-20 15:04 GMT+02:00 Thomas Darimont <thomas.darimont(a)googlemail.com>:
That's interesting.
Will there also be support for desktop apps in some way?
What in particular do you think is the problem with the approach used by
the keycloak-installed adapter
and OAuth device flow, guessing you mean: https://tools.ietf.org/html/
draft-ietf-oauth-device-flow-06 ?
Cheers,
Thomas
2017-07-19 16:31 GMT+02:00 Bill Burke <bburke(a)redhat.com>:
> I'm working on something for command line apps. A command-line
> text/plain protocol so that login can happen within a console. I really
> think keycloak-installation or the OAuth device flow is really poor
> solution.
>
>
> On 7/18/17 9:42 AM, Thomas Darimont wrote:
> > Hello folks,
> >
> > I played a bit with the undocumented? [0] keycloak-installed adapter [1]
> > for integrating
> > desktop applications with Keycloak SSO and found some issues with it,
> which
> > I'd like to share.
> > Small explanation for those who are reading the list but don't know the
> > adapter... [2]
> >
> > First some general notes / suggestions:
> > Is the keycloak-installed adapter something that will stay in keycloak
> or
> > was this just a PoC?
> > In the former case I think there are some things that could be improved
> or
> > extended a bit:
> >
> > - Allow users to customize the locale used for the login pages opened by
> > the adapter
> > - Provide customizable response templates (perhaps by leveraging a
> provided
> > ResourceBundle)
> > - Allow to customize pages shown after login / logout served by the
> > keycloak-installed adapter
> > - Add support for TLS (with custom certificates) for https:// with
> localhost
> >
> > I noticed that some browsers (e.g. Chrome) show an error page when
> trying
> > to
> > redirect to the local mini-webserver after a successful login since the
> > mini-webserver
> > (...server-socket) embedded in the adapter doesn't respond with a valid
> > HTTP response.
> > With that fixed, it worked with all browsers I tested (IE, Firefox,
> Chrome).
> >
> > My current modifications of the keycloak-installed adapter
> > (with HTTP response fixes and response customizations) are here:
> > https://github.com/thomasdarimont/keycloak/commit/b8ee52a946
> e73503b1737f5ca7d4520b8484dae8
> >
> > An extended example (using the the modified keycloak-installed adapter)
> can
> > be found here:
> > https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
> >
> > WDYT?
> >
> > Cheers,
> > Thomas
> >
> > [0] Not mentioned here:
> > https://keycloak.gitbooks.io/documentation/securing_apps/top
> ics/oidc/java/java-adapters.html
> >
> > [1] https://github.com/keycloak/keycloak/tree/master/adapters/oi
> dc/installed
> >
> > [2] For those that haven't seen the adapter yet, it allows to
> authenticate
> > against Keycloak
> > from a desktop app (e.g. swing, javafx) by opening a desktop browser
> window
> > where a user
> > uses the regular keycloak login pages to login.
> > The trick is now that login page is opened with redirect URL that
> points to
> > a small local
> > "web server" (server-socket) on a free ephemeral port which is
started
> by
> > the adapter.
> >
> > After logging in the mini web-server receives performs the
> authenorization
> > code flow and eventually receives the tokens (access_token,
> refresh_token,
> > id_token) which can then be
> > used to call backend services from the client or retrieve new tokens
> >
> > A nice side effect of this is, that the desktop application never sees a
> > users
> > password and one can leverage existing SSO sessions.
> > Btw. the google cloud cli uses the same approach to authenticate with
> gcp.
> >
> > The Keycloak repo contains a small example for this:
> > https://github.com/keycloak/keycloak/blob/master/examples/de
> mo-template/customer-app-cli/src/main/java/org/keycloak/
> example/CustomerCli.java
> > _______________________________________________
> > 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
>
3:23 p.m.
What's wrong? The fact you have to cut and paste a code from the
browser to the app.
On 7/20/17 9:04 AM, Thomas Darimont wrote:
That's interesting.
Will there also be support for desktop apps in some way?
What in particular do you think is the problem with the approach used
by the keycloak-installed adapter
and OAuth device flow, guessing you mean:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 ?
Cheers,
Thomas
2017-07-19 16:31 GMT+02:00 Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>>:
I'm working on something for command line apps. A command-line
text/plain protocol so that login can happen within a console. I
really
think keycloak-installation or the OAuth device flow is really poor
solution.
On 7/18/17 9:42 AM, Thomas Darimont wrote:
> Hello folks,
>
> I played a bit with the undocumented? [0] keycloak-installed
adapter [1]
> for integrating
> desktop applications with Keycloak SSO and found some issues
with it, which
> I'd like to share.
> Small explanation for those who are reading the list but don't
know the
> adapter... [2]
>
> First some general notes / suggestions:
> Is the keycloak-installed adapter something that will stay in
keycloak or
> was this just a PoC?
> In the former case I think there are some things that could be
improved or
> extended a bit:
>
> - Allow users to customize the locale used for the login pages
opened by
> the adapter
> - Provide customizable response templates (perhaps by leveraging
a provided
> ResourceBundle)
> - Allow to customize pages shown after login / logout served by the
> keycloak-installed adapter
> - Add support for TLS (with custom certificates) for https://
with localhost
>
> I noticed that some browsers (e.g. Chrome) show an error page
when trying
> to
> redirect to the local mini-webserver after a successful login
since the
> mini-webserver
> (...server-socket) embedded in the adapter doesn't respond with
a valid
> HTTP response.
> With that fixed, it worked with all browsers I tested (IE,
Firefox, Chrome).
>
> My current modifications of the keycloak-installed adapter
> (with HTTP response fixes and response customizations) are here:
>
https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5...
<https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5...
>
> An extended example (using the the modified keycloak-installed
adapter) can
> be found here:
>
https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
<https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1>
>
> WDYT?
>
> Cheers,
> Thomas
>
> [0] Not mentioned here:
>
https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java...
<https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java...
>
> [1]
https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed
<https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed>
>
> [2] For those that haven't seen the adapter yet, it allows to
authenticate
> against Keycloak
> from a desktop app (e.g. swing, javafx) by opening a desktop
browser window
> where a user
> uses the regular keycloak login pages to login.
> The trick is now that login page is opened with redirect URL
that points to
> a small local
> "web server" (server-socket) on a free ephemeral port which is
started by
> the adapter.
>
> After logging in the mini web-server receives performs the
authenorization
> code flow and eventually receives the tokens (access_token,
refresh_token,
> id_token) which can then be
> used to call backend services from the client or retrieve new tokens
>
> A nice side effect of this is, that the desktop application
never sees a
> users
> password and one can leverage existing SSO sessions.
> Btw. the google cloud cli uses the same approach to authenticate
with gcp.
>
> The Keycloak repo contains a small example for this:
>
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/c...
<https://github.com/keycloak/keycloak/blob/master/examples/demo-template/c...
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
3:41 p.m.
Hi Bill,
actually that's not the way it works - there is no manuall copying of the
auth-code needed
in the case of desktop apps.
An example gist can be found at [1]
It works as follows:
When a user wants to login via a desktop app (e.g. swing, javafx) a desktop
browser
is opened window where a user uses the regular keycloak login pages to
login.
The trick is now that login page is opened with redirect URL that points to
a small local
"web server" (server-socket) on a free ephemeral port listening on
localhost
(which should be rather 127.0.0.1 according to [0]) which is started by the
adapter.
After logging in the mini web-server receives the auth code and performs
the via the
redirect uri: localhost:XXXXX and performs the remaioning authorization
code flow.
The keycloak-installed adapter eventually receives the tokens (access_token,
refresh_token, id_token)
which can then be used to call backend services from the client or retrieve
new tokens.
A nice side effect of this is, that the desktop application never sees a
users
password and one can leverage existing SSO sessions.
Btw. the google cloud cli uses the same approach to authenticate with gcp.
[0] https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12#section-8.3
[1] https://gist.github.com/thomasdarimont/ca16080145d226e50628d5696ffb9508
(in the client in Keycloaks needs to allow http://localhost as valid
redirect uri - should rather be http://127.0.0.1)
Cheers,
Thomas
2017-07-20 15:23 GMT+02:00 Bill Burke <bburke(a)redhat.com>:
What's wrong? The fact you have to cut and paste a code from the
browser
to the app.
On 7/20/17 9:04 AM, Thomas Darimont wrote:
That's interesting.
Will there also be support for desktop apps in some way?
What in particular do you think is the problem with the approach used by
the keycloak-installed adapter
and OAuth device flow, guessing you mean: https://tools.ietf.org/html/
draft-ietf-oauth-device-flow-06 ?
Cheers,
Thomas
2017-07-19 16:31 GMT+02:00 Bill Burke <bburke(a)redhat.com>:
> I'm working on something for command line apps. A command-line
> text/plain protocol so that login can happen within a console. I really
> think keycloak-installation or the OAuth device flow is really poor
> solution.
>
>
> On 7/18/17 9:42 AM, Thomas Darimont wrote:
> > Hello folks,
> >
> > I played a bit with the undocumented? [0] keycloak-installed adapter [1]
> > for integrating
> > desktop applications with Keycloak SSO and found some issues with it,
> which
> > I'd like to share.
> > Small explanation for those who are reading the list but don't know the
> > adapter... [2]
> >
> > First some general notes / suggestions:
> > Is the keycloak-installed adapter something that will stay in keycloak
> or
> > was this just a PoC?
> > In the former case I think there are some things that could be improved
> or
> > extended a bit:
> >
> > - Allow users to customize the locale used for the login pages opened by
> > the adapter
> > - Provide customizable response templates (perhaps by leveraging a
> provided
> > ResourceBundle)
> > - Allow to customize pages shown after login / logout served by the
> > keycloak-installed adapter
> > - Add support for TLS (with custom certificates) for https:// with
> localhost
> >
> > I noticed that some browsers (e.g. Chrome) show an error page when
> trying
> > to
> > redirect to the local mini-webserver after a successful login since the
> > mini-webserver
> > (...server-socket) embedded in the adapter doesn't respond with a valid
> > HTTP response.
> > With that fixed, it worked with all browsers I tested (IE, Firefox,
> Chrome).
> >
> > My current modifications of the keycloak-installed adapter
> > (with HTTP response fixes and response customizations) are here:
> > https://github.com/thomasdarimont/keycloak/commit/b8ee52a946
> e73503b1737f5ca7d4520b8484dae8
> >
> > An extended example (using the the modified keycloak-installed adapter)
> can
> > be found here:
> > https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
> >
> > WDYT?
> >
> > Cheers,
> > Thomas
> >
> > [0] Not mentioned here:
> > https://keycloak.gitbooks.io/documentation/securing_apps/top
> ics/oidc/java/java-adapters.html
> >
> > [1] https://github.com/keycloak/keycloak/tree/master/adapters/oi
> dc/installed
> >
> > [2] For those that haven't seen the adapter yet, it allows to
> authenticate
> > against Keycloak
> > from a desktop app (e.g. swing, javafx) by opening a desktop browser
> window
> > where a user
> > uses the regular keycloak login pages to login.
> > The trick is now that login page is opened with redirect URL that
> points to
> > a small local
> > "web server" (server-socket) on a free ephemeral port which is
started
> by
> > the adapter.
> >
> > After logging in the mini web-server receives performs the
> authenorization
> > code flow and eventually receives the tokens (access_token,
> refresh_token,
> > id_token) which can then be
> > used to call backend services from the client or retrieve new tokens
> >
> > A nice side effect of this is, that the desktop application never sees a
> > users
> > password and one can leverage existing SSO sessions.
> > Btw. the google cloud cli uses the same approach to authenticate with
> gcp.
> >
> > The Keycloak repo contains a small example for this:
> > https://github.com/keycloak/keycloak/blob/master/examples/de
> mo-template/customer-app-cli/src/main/java/org/keycloak/
> example/CustomerCli.java
> > _______________________________________________
> > 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
>
3:56 p.m.
Still crap for command line apps where all you have is a console window.
On 7/20/17 9:41 AM, Thomas Darimont wrote:
Hi Bill,
actually that's not the way it works - there is no manuall copying of
the auth-code needed
in the case of desktop apps.
An example gist can be found at [1]
It works as follows:
When a user wants to login via a desktop app (e.g. swing, javafx) a
desktop browser
is opened window where a user uses the regular keycloak login pages to
login.
The trick is now that login page is opened with redirect URL that
points to a small local
"web server" (server-socket) on a free ephemeral port listening on
localhost
(which should berather 127.0.0.1 according to [0]) which is started by
the adapter.
After logging in the mini web-server receives the auth code and
performs the via the
redirect uri: localhost:XXXXX and performs the remaioning
authorization code flow.
The keycloak-installed adapter eventually receives the tokens
(access_token, refresh_token, id_token)
which can then be used to call backend services from the client or
retrieve new tokens.
A nice side effect of this is, that the desktop application never sees
a users
password and one can leverage existing SSO sessions.
Btw. the google cloud cli uses the same approach to authenticate with gcp.
[0]
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12#section-8.3
[1]
https://gist.github.com/thomasdarimont/ca16080145d226e50628d5696ffb9508
(in the client in Keycloaks needs to allow http://localhost as valid
redirect uri - should rather be http://127.0.0.1)
Cheers,
Thomas
2017-07-20 15:23 GMT+02:00 Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>>:
What's wrong? The fact you have to cut and paste a code from the
browser to the app.
On 7/20/17 9:04 AM, Thomas Darimont wrote:
> That's interesting.
>
> Will there also be support for desktop apps in some way?
>
> What in particular do you think is the problem with the approach
> used by the keycloak-installed adapter
> and OAuth device flow, guessing you mean:
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06
> <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06> ?
>
> Cheers,
> Thomas
>
>
>
> 2017-07-19 16:31 GMT+02:00 Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>>:
>
> I'm working on something for command line apps. A command-line
> text/plain protocol so that login can happen within a
> console. I really
> think keycloak-installation or the OAuth device flow is
> really poor
> solution.
>
>
> On 7/18/17 9:42 AM, Thomas Darimont wrote:
> > Hello folks,
> >
> > I played a bit with the undocumented? [0]
> keycloak-installed adapter [1]
> > for integrating
> > desktop applications with Keycloak SSO and found some
> issues with it, which
> > I'd like to share.
> > Small explanation for those who are reading the list but
> don't know the
> > adapter... [2]
> >
> > First some general notes / suggestions:
> > Is the keycloak-installed adapter something that will stay
> in keycloak or
> > was this just a PoC?
> > In the former case I think there are some things that could
> be improved or
> > extended a bit:
> >
> > - Allow users to customize the locale used for the login
> pages opened by
> > the adapter
> > - Provide customizable response templates (perhaps by
> leveraging a provided
> > ResourceBundle)
> > - Allow to customize pages shown after login / logout
> served by the
> > keycloak-installed adapter
> > - Add support for TLS (with custom certificates) for
> https:// with localhost
> >
> > I noticed that some browsers (e.g. Chrome) show an error
> page when trying
> > to
> > redirect to the local mini-webserver after a successful
> login since the
> > mini-webserver
> > (...server-socket) embedded in the adapter doesn't respond
> with a valid
> > HTTP response.
> > With that fixed, it worked with all browsers I tested (IE,
> Firefox, Chrome).
> >
> > My current modifications of the keycloak-installed adapter
> > (with HTTP response fixes and response customizations) are
> here:
> >
>
https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5...
>
<https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5...
> >
> > An extended example (using the the modified
> keycloak-installed adapter) can
> > be found here:
> >
> https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
>
<https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1>
> >
> > WDYT?
> >
> > Cheers,
> > Thomas
> >
> > [0] Not mentioned here:
> >
>
https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java...
>
<https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java...
> >
> > [1]
> https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed
>
<https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed>
> >
> > [2] For those that haven't seen the adapter yet, it allows
> to authenticate
> > against Keycloak
> > from a desktop app (e.g. swing, javafx) by opening a
> desktop browser window
> > where a user
> > uses the regular keycloak login pages to login.
> > The trick is now that login page is opened with redirect
> URL that points to
> > a small local
> > "web server" (server-socket) on a free ephemeral port which
> is started by
> > the adapter.
> >
> > After logging in the mini web-server receives performs the
> authenorization
> > code flow and eventually receives the tokens (access_token,
> refresh_token,
> > id_token) which can then be
> > used to call backend services from the client or retrieve
> new tokens
> >
> > A nice side effect of this is, that the desktop application
> never sees a
> > users
> > password and one can leverage existing SSO sessions.
> > Btw. the google cloud cli uses the same approach to
> authenticate with gcp.
> >
> > The Keycloak repo contains a small example for this:
> >
>
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/c...
>
<https://github.com/keycloak/keycloak/blob/master/examples/demo-template/c...
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
4:01 p.m.
I can understand that working with cli-apps are a bit awkward to work with
in the context of OAuth 2.0, but I was specifically talking about desktop
apps ;-)
Cheers,
Thomas
2017-07-20 15:56 GMT+02:00 Bill Burke <bburke(a)redhat.com>:
Still crap for command line apps where all you have is a console
window.
On 7/20/17 9:41 AM, Thomas Darimont wrote:
Hi Bill,
actually that's not the way it works - there is no manuall copying of the
auth-code needed
in the case of desktop apps.
An example gist can be found at [1]
It works as follows:
When a user wants to login via a desktop app (e.g. swing, javafx) a
desktop browser
is opened window where a user uses the regular keycloak login pages to
login.
The trick is now that login page is opened with redirect URL that points
to a small local
"web server" (server-socket) on a free ephemeral port listening on
localhost
(which should be rather 127.0.0.1 according to [0]) which is started by
the adapter.
After logging in the mini web-server receives the auth code and performs
the via the
redirect uri: localhost:XXXXX and performs the remaioning authorization
code flow.
The keycloak-installed adapter eventually receives the tokens (access_token,
refresh_token, id_token)
which can then be used to call backend services from the client or
retrieve new tokens.
A nice side effect of this is, that the desktop application never sees a
users
password and one can leverage existing SSO sessions.
Btw. the google cloud cli uses the same approach to authenticate with gcp.
[0] https://tools.ietf.org/html/draft-ietf-oauth-native-
apps-12#section-8.3
[1] https://gist.github.com/thomasdarimont/ca16080145d226e50628d5696ffb95
08
(in the client in Keycloaks needs to allow http://localhost as valid
redirect uri - should rather be http://127.0.0.1)
Cheers,
Thomas
2017-07-20 15:23 GMT+02:00 Bill Burke <bburke(a)redhat.com>:
> What's wrong? The fact you have to cut and paste a code from the browser
> to the app.
>
> On 7/20/17 9:04 AM, Thomas Darimont wrote:
>
> That's interesting.
>
> Will there also be support for desktop apps in some way?
>
> What in particular do you think is the problem with the approach used by
> the keycloak-installed adapter
> and OAuth device flow, guessing you mean: https://tools.ietf.org/html/dr
> aft-ietf-oauth-device-flow-06 ?
>
> Cheers,
> Thomas
>
>
>
> 2017-07-19 16:31 GMT+02:00 Bill Burke <bburke(a)redhat.com>:
>
>> I'm working on something for command line apps. A command-line
>> text/plain protocol so that login can happen within a console. I really
>> think keycloak-installation or the OAuth device flow is really poor
>> solution.
>>
>>
>> On 7/18/17 9:42 AM, Thomas Darimont wrote:
>> > Hello folks,
>> >
>> > I played a bit with the undocumented? [0] keycloak-installed adapter
>> [1]
>> > for integrating
>> > desktop applications with Keycloak SSO and found some issues with it,
>> which
>> > I'd like to share.
>> > Small explanation for those who are reading the list but don't know the
>> > adapter... [2]
>> >
>> > First some general notes / suggestions:
>> > Is the keycloak-installed adapter something that will stay in keycloak
>> or
>> > was this just a PoC?
>> > In the former case I think there are some things that could be
>> improved or
>> > extended a bit:
>> >
>> > - Allow users to customize the locale used for the login pages opened
>> by
>> > the adapter
>> > - Provide customizable response templates (perhaps by leveraging a
>> provided
>> > ResourceBundle)
>> > - Allow to customize pages shown after login / logout served by the
>> > keycloak-installed adapter
>> > - Add support for TLS (with custom certificates) for https:// with
>> localhost
>> >
>> > I noticed that some browsers (e.g. Chrome) show an error page when
>> trying
>> > to
>> > redirect to the local mini-webserver after a successful login since the
>> > mini-webserver
>> > (...server-socket) embedded in the adapter doesn't respond with a valid
>> > HTTP response.
>> > With that fixed, it worked with all browsers I tested (IE, Firefox,
>> Chrome).
>> >
>> > My current modifications of the keycloak-installed adapter
>> > (with HTTP response fixes and response customizations) are here:
>> > https://github.com/thomasdarimont/keycloak/commit/b8ee52a946
>> e73503b1737f5ca7d4520b8484dae8
>> >
>> > An extended example (using the the modified keycloak-installed
>> adapter) can
>> > be found here:
>> > https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6f
>> be2c013c5f1
>> >
>> > WDYT?
>> >
>> > Cheers,
>> > Thomas
>> >
>> > [0] Not mentioned here:
>> > https://keycloak.gitbooks.io/documentation/securing_apps/top
>> ics/oidc/java/java-adapters.html
>> >
>> > [1] https://github.com/keycloak/keycloak/tree/master/adapters/oi
>> dc/installed
>> >
>> > [2] For those that haven't seen the adapter yet, it allows to
>> authenticate
>> > against Keycloak
>> > from a desktop app (e.g. swing, javafx) by opening a desktop browser
>> window
>> > where a user
>> > uses the regular keycloak login pages to login.
>> > The trick is now that login page is opened with redirect URL that
>> points to
>> > a small local
>> > "web server" (server-socket) on a free ephemeral port which is
started
>> by
>> > the adapter.
>> >
>> > After logging in the mini web-server receives performs the
>> authenorization
>> > code flow and eventually receives the tokens (access_token,
>> refresh_token,
>> > id_token) which can then be
>> > used to call backend services from the client or retrieve new tokens
>> >
>> > A nice side effect of this is, that the desktop application never sees
>> a
>> > users
>> > password and one can leverage existing SSO sessions.
>> > Btw. the google cloud cli uses the same approach to authenticate with
>> gcp.
>> >
>> > The Keycloak repo contains a small example for this:
>> > https://github.com/keycloak/keycloak/blob/master/examples/de
>> mo-template/customer-app-cli/src/main/java/org/keycloak/exam
>> ple/CustomerCli.java
>> > _______________________________________________
>> > 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
>>
>
>
>
9:52 a.m.
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
7:08 p.m.
Hello,
quick followup...
Since there was no documentation for the KeycloakInstalled adapter yet, I
just wrote a short section for the manual.
https://github.com/keycloak/keycloak-documentation/pull/206
Looking forward to your feedback.
Cheers,
Thomas
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
>
3:30 a.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
+==============================+
7:56 a.m.
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
<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(a)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(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
+==============================+
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:25 p.m.
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_C...
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(a)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(a)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(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 <lj(a)jguru.se>
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
_______________________________________________
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
+==============================+
2297
days inactive
2467
days old
13 comments
4 participants
participants (4)
-
Bill Burke -
Hendrik Ebbers -
Lennart Jörelid -
Thomas Darimont