Create "online session" from offline session
by Niels Bertram
Hi devs,
we are trying to turn an offline session back into an "online session" for
which we can generate cookies and send them to the clients browser.
I tried to create a user session with AuthenticationManager but for some
reason the created session is not showing up as a proper in the user
account management section. Is there anything that needs to happen after
this session is created to make it a normal user session?
AuthenticatedClientSessionModel clientSession =
session.sessions().createClientSession(realm, client, offlineSession);
We have a mobile app that uses offline_access to create an "always logged"
in experience for the app user. However when we open a SSO-enabled website
in the app (WebView), there is no KEYCLOAK_SESSION cookie to allow the web
page to initiate a successful pre-auth check.
We wrote a custom resource which we call in our webview to "redirect" the
user to an SSO enabled site:
1. authenticate the user
AuthResult auth = new AppAuthManager().authenticateBearerToken(session)
2. load a valid userSession
UserSessionModel userSession = session.sessions().getUserSession(realm,
token.getSessionState());
3. create the session cookies
AuthenticationManager.createLoginCookie(session, realm, user, userSession,
ctx.getUri(), ctx.getConnection());
4. forward the user to the SSO enabled website
5. SSO enabled website would do a normal pre-auth check with prompt=none
There was a similar conversation about the "lost" session in KEYCLOAK-4201
<https://issues.jboss.org/browse/KEYCLOAK-420>, but that one did not go as
far as creating a new session.
Anyone of you got any clever idea on how do "preload" a valid SSO session
into a WebView?
Cheers,
Niels
PS. we are on RH-SSO 7.2.4 so roughly Keycloak 3.4.3
6 years, 2 months
Improved CSP support
by Johannes Knutsen
Hi,
I am currently looking at improvements in the Content Security Policy
(CSP) support.
In our deployment, we have security requirements stating that a CSP
header should be used and inline scripts, styles and resources should
be blocked. For example by setting a CSP value like default-src
'self';.
Such a policy breaks Keycloak's manipulation of the browser history
implemented in the BrowserHistoryHelper, since the
JavascriptHistoryReplace injects an inline JavaScript.
The simplest workaround is to also inject a nonce value or SHA hash of
the script to the existing CSP header.
However, while implementing this, I found that a CSP nonce in general
would be nice to have available in any template context. This will
also make it easier to migrate the default Keycloak theme to support
stricter security policies.
An example implementation can be found here:
https://github.com/knutz3n/keycloak/commit/c6cfb3efa2942d7569066c0e4bd90a...
Would you be interested in merging a change like the one above? If
not, what is your view on how to allow stricter content security
policies?
Tests and documentation is currently missing, but I will add both if
this is something you would consider merging.
As a note, I have also done some work on supporting a strict CSP value
for the default theme. But there are some issues with included 3rd
party scripts which must/should be resolved. Let me know if you want
more details regarding this.
Best regards,
Johannes Knutsen
6 years, 2 months
Column Sorting
by KevinO
Is there any opposition to me adding column sorting? There is the ticket
for it:
https://issues.jboss.org/browse/KEYCLOAK-4676
I've tested a solution that uses standard angular ordering. I don't want to
update all the tables if this is a feature that is not wanted.
Here is what one option of sorting would look like using Font-Awesoms
chevron as the clickable item.
[image: image.png]
[image: image.png]
6 years, 2 months
PR for adding 'roles' and 'web-origins' client scopes
by Marek Posolda
I've sent PR https://github.com/keycloak/keycloak/pull/5602 . Summary of
changes:
- The roles and allowed-origins are not added automatically to the
access tokens now. Instead of it, the PR introduces 2 default client
scopes: 'roles' and 'web-origins' which adds them
- Client scope 'web-origins' adds allowed-origins to the access token
similarly like it was before. So the only advantage is, that it is
possible to remove clientScope/protocolMapper if you don't need web
origins in the token
- Client scope 'roles' contains protocol mappers for add roles to the
access tokens. By default, they are added to the claims "realm_access"
and "resource_access" exactly as it was before. However it is easier to
move to completely different claims. The PR doesn't introduce new
protocol mapper implementation for roles, but uses the existing
implementations UserRealmRoleMappingMapper and
UserClientRoleMappingMapper. As a side-effect, it fixes some bug in
those mappers claimed by many community users -
https://issues.jboss.org/browse/KEYCLOAK-5259
- PR introduces new protocol mapper implementation
AudienceResolveProtocolMapper, which adds audience of all the clients,
for which at least one client role is available in the token. This is
added by default to the 'roles' client scope
- There is new switch "Include in Token Scope" on the Client Scope. It
is applicable only for OIDC clients. When it is off, the client scope is
not added to the "scope" in the access token. It is used for both
'roles' and 'web-origins' scopes, so those are not in the token by
default now.
- There is some minor addition to ProtocolMapper SPI. Protocol mapper
implementations has "priority" now. This is needed, so that it is
ensured that for example we first "compute" the roles to be put in the
token (including composite roles etc), then eventually add/move some
roles through HardcodedRoleMapper or RoleNameMapper, then figure the
audiences and finally move the roles to proper place in the token (which
is not necessarily hardcoded to "realm_access" and "resource_access"
claims as it was before).
- Migration is handled, so that 'roles' and 'web-origins' scopes are
automatically added during migration and they are added to all the OIDC
confidential/public clients.
WDYT?
Marek
6 years, 2 months
Re: [keycloak-dev] [External] keycloak-dev Digest, Vol 64, Issue 3
by Shyam Gupta, Upendra
Hi Team ,
We have done standalone configuration , but we are struggling with Domain Cluster mode .
We have Angular JS Application ,we have LB in front of key cloak could you please suggest or guide how configuration should be done .
Also may use autoscaling in our production Environment ,please suggest is Domain Cluster Mode suitable for this and if yes how to configure it .
Thanks ,
Upendra
+91 9765552818
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of keycloak-dev-request(a)lists.jboss.org
Sent: Wednesday, October 3, 2018 12:41 PM
To: keycloak-dev(a)lists.jboss.org
Subject: [External] keycloak-dev Digest, Vol 64, Issue 3
Send keycloak-dev mailing list submissions to
keycloak-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
or, via email, send a message with subject or body 'help' to
keycloak-dev-request(a)lists.jboss.org
You can reach the person managing the list at
keycloak-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of keycloak-dev digest..."
Today's Topics:
1. Create "online session" from offline session (Niels Bertram)
2. Re: Column Sorting (Stan Silvert)
3. Re: Create "online session" from offline session (Marek Posolda)
4. Re: Create "online session" from offline session (Niels Bertram)
5. PR for adding 'roles' and 'web-origins' client scopes
(Marek Posolda)
6. Re: Create "online session" from offline session (Marek Posolda)
----------------------------------------------------------------------
Message: 1
Date: Tue, 2 Oct 2018 16:24:20 +1000
From: Niels Bertram <nielsbne(a)gmail.com>
Subject: [keycloak-dev] Create "online session" from offline session
To: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Message-ID:
<CAPLPyg=MqBHWsA0E2-Sd=UbYh-E+mHAb33F=cOUv9xSkxzPhxg(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi devs,
we are trying to turn an offline session back into an "online session" for which we can generate cookies and send them to the clients browser.
I tried to create a user session with AuthenticationManager but for some reason the created session is not showing up as a proper in the user account management section. Is there anything that needs to happen after this session is created to make it a normal user session?
AuthenticatedClientSessionModel clientSession = session.sessions().createClientSession(realm, client, offlineSession);
We have a mobile app that uses offline_access to create an "always logged"
in experience for the app user. However when we open a SSO-enabled website in the app (WebView), there is no KEYCLOAK_SESSION cookie to allow the web page to initiate a successful pre-auth check.
We wrote a custom resource which we call in our webview to "redirect" the user to an SSO enabled site:
1. authenticate the user
AuthResult auth = new AppAuthManager().authenticateBearerToken(session)
2. load a valid userSession
UserSessionModel userSession = session.sessions().getUserSession(realm,
token.getSessionState());
3. create the session cookies
AuthenticationManager.createLoginCookie(session, realm, user, userSession, ctx.getUri(), ctx.getConnection());
4. forward the user to the SSO enabled website
5. SSO enabled website would do a normal pre-auth check with prompt=none
There was a similar conversation about the "lost" session in KEYCLOAK-4201 <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro...>, but that one did not go as far as creating a new session.
Anyone of you got any clever idea on how do "preload" a valid SSO session into a WebView?
Cheers,
Niels
PS. we are on RH-SSO 7.2.4 so roughly Keycloak 3.4.3
------------------------------
Message: 2
Date: Tue, 2 Oct 2018 06:58:20 -0400
From: Stan Silvert <ssilvert(a)redhat.com>
Subject: Re: [keycloak-dev] Column Sorting
To: keycloak-dev(a)lists.jboss.org
Message-ID: <fcc562ce-4a46-f9a6-09ff-c21c48490cd9(a)redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
If you have a PR for this we would welcome it.? However, it might be quite awhile before it can be merged into the code base because we are fast approaching an extended feature freeze.
Stan
On 10/1/2018 9:05 PM, KevinO wrote:
> Is there any opposition to me adding column sorting? There is the
> ticket for it:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_
> browse_KEYCLOAK-2D4676&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8Irw
> NKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0mrWqin
> gS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=GXdUVsHcO0O5XcZ7E
> 1ivVWk_t-E1Wdgf3ThuAK6Ldvk&e=
>
> I've tested a solution that uses standard angular ordering. I don't
> want to update all the tables if this is a feature that is not wanted.
>
> Here is what one option of sorting would look like using Font-Awesoms
> chevron as the clickable item.
> [image: image.png]
> [image: image.png]
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_m
> ailman_listinfo_keycloak-2Ddev&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nO
> HrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3y
> W0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=vtPzZKTG6
> Ju-WczYEuZ1TJP2HOV-5yvr7Kv5ajKy8gg&e=
------------------------------
Message: 3
Date: Tue, 2 Oct 2018 16:33:00 +0200
From: Marek Posolda <mposolda(a)redhat.com>
Subject: Re: [keycloak-dev] Create "online session" from offline
session
To: Niels Bertram <nielsbne(a)gmail.com>,keycloak-dev
<keycloak-dev(a)lists.jboss.org>
Message-ID: <0ca41d60-abd2-f716-91ae-9ac0ba00444d(a)redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
I suggest to use the flow like this:
1) Exchange the offline token for the 3 tokens, which will include the triplet of (access token, id token, offline token).
2) Then you can pass the just retrieved IDToken in the authentication request in the "id_token_hint" parameter.
3) Then you will need to create Authenticator (see our docs/quickstarts for more details), which will be able to see if "id_token_hint" was sent and then verify this token and authenticate user if it was ok. You can probably use some existing code from IDToken introspection endpoint. If parameter is not used, authenticator can be just ignored during the authentication flow.
4) As last step, you will need to add this authenticator to the browser authentication flow.
This will cause that if IDToken is sent, it will be able to use it to authenticate the user and hence new UserSessionModel (+cookies and all of this) will be properly created by Keycloak itself.
If you manage to make this working, we will be happy if you contribute it in the PR :) As this is described in the OIDC specification (see https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_specs_ope... ), but we don't yet implement it.
If you don't want to send PR, you may implement it a bit easier and differently in a non-OIDC standard way (EG. pass the offline_token directly instead of IDToken in step 2).
Marek
On 02/10/18 08:24, Niels Bertram wrote:
> Hi devs,
>
> we are trying to turn an offline session back into an "online session"
> for which we can generate cookies and send them to the clients browser.
>
> I tried to create a user session with AuthenticationManager but for
> some reason the created session is not showing up as a proper in the
> user account management section. Is there anything that needs to
> happen after this session is created to make it a normal user session?
>
> AuthenticatedClientSessionModel clientSession =
> session.sessions().createClientSession(realm, client, offlineSession);
>
> We have a mobile app that uses offline_access to create an "always logged"
> in experience for the app user. However when we open a SSO-enabled
> website in the app (WebView), there is no KEYCLOAK_SESSION cookie to
> allow the web page to initiate a successful pre-auth check.
>
> We wrote a custom resource which we call in our webview to "redirect"
> the user to an SSO enabled site:
>
> 1. authenticate the user
>
> AuthResult auth = new
> AppAuthManager().authenticateBearerToken(session)
>
> 2. load a valid userSession
>
> UserSessionModel userSession =
> session.sessions().getUserSession(realm,
> token.getSessionState());
>
> 3. create the session cookies
>
> AuthenticationManager.createLoginCookie(session, realm, user,
> userSession, ctx.getUri(), ctx.getConnection());
>
> 4. forward the user to the SSO enabled website
>
> 5. SSO enabled website would do a normal pre-auth check with
> prompt=none
>
> There was a similar conversation about the "lost" session in
> KEYCLOAK-4201
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro...>, but that one did not go as far as creating a new session.
>
> Anyone of you got any clever idea on how do "preload" a valid SSO
> session into a WebView?
>
> Cheers,
> Niels
>
> PS. we are on RH-SSO 7.2.4 so roughly Keycloak 3.4.3
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_m
> ailman_listinfo_keycloak-2Ddev&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nO
> HrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3y
> W0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=vtPzZKTG6
> Ju-WczYEuZ1TJP2HOV-5yvr7Kv5ajKy8gg&e=
------------------------------
Message: 4
Date: Wed, 3 Oct 2018 01:15:05 +1000
From: Niels Bertram <nielsbne(a)gmail.com>
Subject: Re: [keycloak-dev] Create "online session" from offline
session
To: Marek Posolda <mposolda(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Message-ID:
<CAPLPygkndifFFNXr27ic8MPiy_oc7Z3wM72UMGHGMnamfducHA(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Thanks for the response Marek. I implemented a custom authenticator before so that makes all total sense. The parts I am a bit worried about is:
a) the GET implementation would require use to send the IDToken unprotected in the URL (POST is fine)
b) a mobile app from which we want to initiate the "sign me in and then redirect me to another website" would effectively need to whitelist every possible URL that it can redirect to.
If I send a PR to latest Keycloak, any chance that can be patched into current or next version of RH-SSO?
Cheers,
Niels
On Wed, Oct 3, 2018 at 12:33 AM Marek Posolda <mposolda(a)redhat.com> wrote:
> I suggest to use the flow like this:
> 1) Exchange the offline token for the 3 tokens, which will include the
> triplet of (access token, id token, offline token).
>
> 2) Then you can pass the just retrieved IDToken in the authentication
> request in the "id_token_hint" parameter.
>
> 3) Then you will need to create Authenticator (see our
> docs/quickstarts for more details), which will be able to see if
> "id_token_hint" was sent and then verify this token and authenticate
> user if it was ok. You can probably use some existing code from
> IDToken introspection endpoint. If parameter is not used,
> authenticator can be just ignored during the authentication flow.
>
> 4) As last step, you will need to add this authenticator to the
> browser authentication flow.
>
> This will cause that if IDToken is sent, it will be able to use it to
> authenticate the user and hence new UserSessionModel (+cookies and all
> of this) will be properly created by Keycloak itself.
>
> If you manage to make this working, we will be happy if you contribute
> it in the PR :) As this is described in the OIDC specification (see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_specs_
> openid-2Dconnect-2Dcore-2D1-5F0.html-23AuthRequest&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=WMK8NemyUzNtZIsMw_iLiVxqx9cKk4FCx2FM4hu00KI&e= ), but we don't yet implement it.
>
> If you don't want to send PR, you may implement it a bit easier and
> differently in a non-OIDC standard way (EG. pass the offline_token
> directly instead of IDToken in step 2).
>
> Marek
>
> On 02/10/18 08:24, Niels Bertram wrote:
> > Hi devs,
> >
> > we are trying to turn an offline session back into an "online session"
> for
> > which we can generate cookies and send them to the clients browser.
> >
> > I tried to create a user session with AuthenticationManager but for
> > some reason the created session is not showing up as a proper in the
> > user account management section. Is there anything that needs to
> > happen after this session is created to make it a normal user session?
> >
> > AuthenticatedClientSessionModel clientSession =
> > session.sessions().createClientSession(realm, client,
> > offlineSession);
> >
> > We have a mobile app that uses offline_access to create an "always
> logged"
> > in experience for the app user. However when we open a SSO-enabled
> website
> > in the app (WebView), there is no KEYCLOAK_SESSION cookie to allow
> > the
> web
> > page to initiate a successful pre-auth check.
> >
> > We wrote a custom resource which we call in our webview to
> > "redirect" the user to an SSO enabled site:
> >
> > 1. authenticate the user
> >
> > AuthResult auth = new
> > AppAuthManager().authenticateBearerToken(session)
> >
> > 2. load a valid userSession
> >
> > UserSessionModel userSession =
> > session.sessions().getUserSession(realm,
> > token.getSessionState());
> >
> > 3. create the session cookies
> >
> > AuthenticationManager.createLoginCookie(session, realm, user,
> userSession,
> > ctx.getUri(), ctx.getConnection());
> >
> > 4. forward the user to the SSO enabled website
> >
> > 5. SSO enabled website would do a normal pre-auth check with
> > prompt=none
> >
> > There was a similar conversation about the "lost" session in
> KEYCLOAK-4201
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.o
> > rg_browse_KEYCLOAK-2D420&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK
> > 8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0
> > mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=ZMc4ZmEk4
> > 8Nmomy36jvaoA3dXdGc4akKoAsKI8KSkuE&e=>, but that one did not go
> as
> > far as creating a new session.
> >
> > Anyone of you got any clever idea on how do "preload" a valid SSO
> > session into a WebView?
> >
> > Cheers,
> > Niels
> >
> > PS. we are on RH-SSO 7.2.4 so roughly Keycloak 3.4.3
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org
> > _mailman_listinfo_keycloak-2Ddev&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJv
> > U8nOHrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbE
> > LXY-3yW0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=v
> > tPzZKTG6Ju-WczYEuZ1TJP2HOV-5yvr7Kv5ajKy8gg&e=
>
>
>
------------------------------
Message: 5
Date: Tue, 2 Oct 2018 21:25:34 +0200
From: Marek Posolda <mposolda(a)redhat.com>
Subject: [keycloak-dev] PR for adding 'roles' and 'web-origins' client
scopes
To: "keycloak-dev(a)lists.jboss.org" <keycloak-dev(a)lists.jboss.org>
Message-ID: <c06346c8-e686-4049-c744-5467da8fd7b4(a)redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
I've sent PR https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_keycloak_... . Summary of
changes:
- The roles and allowed-origins are not added automatically to the access tokens now. Instead of it, the PR introduces 2 default client
scopes: 'roles' and 'web-origins' which adds them
- Client scope 'web-origins' adds allowed-origins to the access token similarly like it was before. So the only advantage is, that it is possible to remove clientScope/protocolMapper if you don't need web origins in the token
- Client scope 'roles' contains protocol mappers for add roles to the access tokens. By default, they are added to the claims "realm_access"
and "resource_access" exactly as it was before. However it is easier to move to completely different claims. The PR doesn't introduce new protocol mapper implementation for roles, but uses the existing implementations UserRealmRoleMappingMapper and UserClientRoleMappingMapper. As a side-effect, it fixes some bug in those mappers claimed by many community users - https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro...
- PR introduces new protocol mapper implementation AudienceResolveProtocolMapper, which adds audience of all the clients, for which at least one client role is available in the token. This is added by default to the 'roles' client scope
- There is new switch "Include in Token Scope" on the Client Scope. It is applicable only for OIDC clients. When it is off, the client scope is not added to the "scope" in the access token. It is used for both 'roles' and 'web-origins' scopes, so those are not in the token by default now.
- There is some minor addition to ProtocolMapper SPI. Protocol mapper implementations has "priority" now. This is needed, so that it is ensured that for example we first "compute" the roles to be put in the token (including composite roles etc), then eventually add/move some roles through HardcodedRoleMapper or RoleNameMapper, then figure the audiences and finally move the roles to proper place in the token (which is not necessarily hardcoded to "realm_access" and "resource_access"
claims as it was before).
- Migration is handled, so that 'roles' and 'web-origins' scopes are automatically added during migration and they are added to all the OIDC confidential/public clients.
WDYT?
Marek
------------------------------
Message: 6
Date: Wed, 3 Oct 2018 09:10:31 +0200
From: Marek Posolda <mposolda(a)redhat.com>
Subject: Re: [keycloak-dev] Create "online session" from offline
session
To: Niels Bertram <nielsbne(a)gmail.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Message-ID: <fd2a86b5-0550-2c13-d4f4-e9cbbea62864(a)redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 02/10/18 17:15, Niels Bertram wrote:
> Thanks for the response Marek. I implemented a custom authenticator
> before so that makes all total sense. The parts I am a bit worried
> about is:
>
> a) the GET implementation would require use to send the IDToken
> unprotected in the URL (POST is fine)
I see. This makes sense and we support sending POST request to the initial Authentication endpoint. Maybe you can add a flag to the authenticator like "Allow POST method only" to specify if it accepts just POST or allow both POST and GET? Flag can be set to ON by default (hence accept only POST).
>
> b) a mobile app from which we want to initiate the "sign me in and
> then redirect me to another website" would effectively need to
> whitelist every possible URL that it can redirect to.
>
> If I send a PR to latest Keycloak, any chance that can be patched into
> current or next version of RH-SSO?
Yes, once the PR is accepted, it always go to the latest Keycloak upstream and latest Keycloak always "turns" after some time to RH-SSO.
Some details about this https://urldefense.proofpoint.com/v2/url?u=https-3A__www.keycloak.org_sup... .
Just a note that we're close to feature freeze for Keycloak 4.x (RHSSO 7.3), so if you want it in RHSSO 7.3, you need to be a bit quick though
:) And even then no guarantee as we will need some time for PR review etc.
Marek
>
> Cheers,
> Niels
>
> On Wed, Oct 3, 2018 at 12:33 AM Marek Posolda <mposolda(a)redhat.com
> <mailto:mposolda@redhat.com>> wrote:
>
> I suggest to use the flow like this:
> 1) Exchange the offline token for the 3 tokens, which will include
> the
> triplet of (access token, id token, offline token).
>
> 2) Then you can pass the just retrieved IDToken in the authentication
> request in the "id_token_hint" parameter.
>
> 3) Then you will need to create Authenticator (see our
> docs/quickstarts
> for more details), which will be able to see if "id_token_hint"
> was sent
> and then verify this token and authenticate user if it was ok. You
> can
> probably use some existing code from IDToken introspection
> endpoint. If
> parameter is not used, authenticator can be just ignored during the
> authentication flow.
>
> 4) As last step, you will need to add this authenticator to the
> browser
> authentication flow.
>
> This will cause that if IDToken is sent, it will be able to use it to
> authenticate the user and hence new UserSessionModel (+cookies and
> all
> of this) will be properly created by Keycloak itself.
>
> If you manage to make this working, we will be happy if you
> contribute
> it in the PR :) As this is described in the OIDC specification (see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_specs_ope...
> ), but
> we don't yet implement it.
>
> If you don't want to send PR, you may implement it a bit easier and
> differently in a non-OIDC standard way (EG. pass the offline_token
> directly instead of IDToken in step 2).
>
> Marek
>
> On 02/10/18 08:24, Niels Bertram wrote:
> > Hi devs,
> >
> > we are trying to turn an offline session back into an "online
> session" for
> > which we can generate cookies and send them to the clients browser.
> >
> > I tried to create a user session with AuthenticationManager but
> for some
> > reason the created session is not showing up as a proper in the user
> > account management section. Is there anything that needs to
> happen after
> > this session is created to make it a normal user session?
> >
> > AuthenticatedClientSessionModel clientSession =
> > session.sessions().createClientSession(realm, client,
> offlineSession);
> >
> > We have a mobile app that uses offline_access to create an
> "always logged"
> > in experience for the app user. However when we open a
> SSO-enabled website
> > in the app (WebView), there is no KEYCLOAK_SESSION cookie to
> allow the web
> > page to initiate a successful pre-auth check.
> >
> > We wrote a custom resource which we call in our webview to
> "redirect" the
> > user to an SSO enabled site:
> >
> > 1. authenticate the user
> >
> > AuthResult auth = new
> AppAuthManager().authenticateBearerToken(session)
> >
> > 2. load a valid userSession
> >
> > UserSessionModel userSession =
> session.sessions().getUserSession(realm,
> > token.getSessionState());
> >
> > 3. create the session cookies
> >
> > AuthenticationManager.createLoginCookie(session, realm, user,
> userSession,
> > ctx.getUri(), ctx.getConnection());
> >
> > 4. forward the user to the SSO enabled website
> >
> > 5. SSO enabled website would do a normal pre-auth check with
> prompt=none
> >
> > There was a similar conversation about the "lost" session in
> KEYCLOAK-4201
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro...>, but that one did
> not go as
> > far as creating a new session.
> >
> > Anyone of you got any clever idea on how do "preload" a valid
> SSO session
> > into a WebView?
> >
> > Cheers,
> > Niels
> >
> > PS. we are on RH-SSO 7.2.4 so roughly Keycloak 3.4.3
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_m
> ailman_listinfo_keycloak-2Ddev&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nO
> HrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3y
> W0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=vtPzZKTG6
> Ju-WczYEuZ1TJP2HOV-5yvr7Kv5ajKy8gg&e=
>
>
------------------------------
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
End of keycloak-dev Digest, Vol 64, Issue 3
*******************************************
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________
www.accenture.com
6 years, 2 months
Partial import - problem with client's default roles
by Dariusz Chrzascik
Hi,
I've encountered an issue when using Admin Console's partial import.
I've enclosed simplified realm configuration that demonstrates the case.
Importing that realm results in exception:
15:45:43,675 ERROR [org.keycloak.services] (default task-103)
KC-SERVICES0038: Error importing roles:
org.keycloak.models.ModelDuplicateException
at
org.keycloak.models.jpa.JpaRealmProvider.addClientRole(JpaRealmProvider.java:228)
at
org.keycloak.models.cache.infinispan.RealmCacheSession.addClientRole(RealmCacheSession.java:683)
at
org.keycloak.models.jpa.ClientAdapter.addRole(ClientAdapter.java:626)
at
org.keycloak.models.utils.RepresentationToModel.importRoles(RepresentationToModel.java:504)
at
org.keycloak.partialimport.RolesPartialImport.doImport(RolesPartialImport.java:98)
at
org.keycloak.partialimport.PartialImportManager.saveResources(PartialImportManager.java:77)
at
org.keycloak.services.resources.admin.RealmAdminResource.partialImport(RealmAdminResource.java:1064)
I've observed that it is caused by importing a realm where client has
roles and some of them are default for that client. This results in
creating a client with default roles first and then creating a roles.
This fails as client creation is accompanied by creating default roles.
Perhaps, it can be solved by making argument "addDefaultRoles" in
RepresentationToModel.createClient configurable from the partialImport.
Currently it is always set to true (see ClientPartialImport.create).
Has anyone encountered that issue or maybe has suggestion how to fix it?
PS:
The workaround is to run partial import twice:
1. for clients only
2. for roles
but in my case it is not an option.
Regards,
Dariusz Chrząścik
CONFIDENTIALITY NOTICE
------------------------------------
This E-mail is intended only to be read or used by the addressee. The information contained in this E-mail message may be confidential information. If you are not the intended recipient, any use, interference with, distribution, disclosure or copying of this material is unauthorized and prohibited. Confidentiality attached to this communication is not waived or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us by return E-mail or telephone NOVOMATIC Technologies Poland S.A. +48 12 258 00 50. Any E-mail attachment may contain software viruses which could damage your own computer system. Whilst reasonable precaution has been taken to minimize this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening any attachments.
------------------------------------
NOVOMATIC Technologies Poland S.A., Poland, Krakowska 368, 32-080 Zabierzów
6 years, 2 months
Latest changes with JGroups discovery in 4.5.0.Final Docker Image
by Schuster Sebastian (INST-CSS/BSV-OS)
Hi everybody,
I think there are some minor issues with the changes in the 4.5.0 Docker image. In docker-entrypoint.sh per default if nothing is specified the jboss.bind.address and jboss.bind.address.private are both set to hostname –i and if nothing is specified standalone-ha mode is used. I find that at least questionable, I think running standalone is a safer default compared to opening JGroups communication on a public interface. However, the default works for us in Kubernetes.
However, the detection whether a profile was specified (if echo "$@" | egrep -v -- "-c "; then) should be improved, only looking for “-c” does not work as “—server-config” is equally possible. Wildfly will die with an error if both are present…
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
6 years, 2 months
