[keycloak-dev] [External] keycloak-dev Digest, Vol 64, Issue 3
Stian Thorgersen
sthorger at redhat.com
Wed Oct 3 07:39:38 EDT 2018
Please use user mailing list (keycloak-user at lists.jboss.org) for general
questions and help. The developer mailing list is dedicated to discussing
development of Keycloak itself, including contributions.
On Wed, 3 Oct 2018 at 12:09, Shyam Gupta, Upendra <
upendra.shyam.gupta at accenture.com> wrote:
> 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 at lists.jboss.org <
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of
> keycloak-dev-request at lists.jboss.org
> Sent: Wednesday, October 3, 2018 12:41 PM
> To: keycloak-dev at lists.jboss.org
> Subject: [External] keycloak-dev Digest, Vol 64, Issue 3
>
> Send keycloak-dev mailing list submissions to
> keycloak-dev at 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_mailman_listinfo_keycloak-2Ddev&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=vtPzZKTG6Ju-WczYEuZ1TJP2HOV-5yvr7Kv5ajKy8gg&e=
> or, via email, send a message with subject or body 'help' to
> keycloak-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> keycloak-dev-owner at 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 at gmail.com>
> Subject: [keycloak-dev] Create "online session" from offline session
> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> Message-ID:
> <CAPLPyg=MqBHWsA0E2-Sd=UbYh-E+mHAb33F=cOUv9xSkxzPhxg at 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_browse_KEYCLOAK-2D420&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=ZMc4ZmEk48Nmomy36jvaoA3dXdGc4akKoAsKI8KSkuE&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
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 2 Oct 2018 06:58:20 -0400
> From: Stan Silvert <ssilvert at redhat.com>
> Subject: Re: [keycloak-dev] Column Sorting
> To: keycloak-dev at lists.jboss.org
> Message-ID: <fcc562ce-4a46-f9a6-09ff-c21c48490cd9 at 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 at 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 at redhat.com>
> Subject: Re: [keycloak-dev] Create "online session" from offline
> session
> To: Niels Bertram <nielsbne at gmail.com>,keycloak-dev
> <keycloak-dev at lists.jboss.org>
> Message-ID: <0ca41d60-abd2-f716-91ae-9ac0ba00444d at 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_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.org_browse_KEYCLOAK-2D420&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=ZMc4ZmEk48Nmomy36jvaoA3dXdGc4akKoAsKI8KSkuE&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 at 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 at gmail.com>
> Subject: Re: [keycloak-dev] Create "online session" from offline
> session
> To: Marek Posolda <mposolda at redhat.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Message-ID:
> <CAPLPygkndifFFNXr27ic8MPiy_oc7Z3wM72UMGHGMnamfducHA at 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 at 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 at 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 at redhat.com>
> Subject: [keycloak-dev] PR for adding 'roles' and 'web-origins' client
> scopes
> To: "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>
> Message-ID: <c06346c8-e686-4049-c744-5467da8fd7b4 at 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_keycloak_pull_5602&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=huhPyNGMhgYLHNSqmXb0f9btGuvjClSYAeXGkDPCHbg&e=
> . 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_browse_KEYCLOAK-2D5259&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=Uqws8bxoWQneaU68lkcYgV55vGM8jQMwXLZJD0KbxL0&e=
>
> - 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 at redhat.com>
> Subject: Re: [keycloak-dev] Create "online session" from offline
> session
> To: Niels Bertram <nielsbne at gmail.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Message-ID: <fd2a86b5-0550-2c13-d4f4-e9cbbea62864 at 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_support.html&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=mo48y52DsFKg-uYJ25AIz8dEdVT7LwYWXUh6Hr6snE0&e=
> .
>
> 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 at redhat.com
> > <mailto:mposolda at 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.org_browse_KEYCLOAK-2D420&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=ZMc4ZmEk48Nmomy36jvaoA3dXdGc4akKoAsKI8KSkuE&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 at lists.jboss.org <mailto:keycloak-dev at 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 at lists.jboss.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_keycloak-2Ddev&d=DwICAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=0u41OaohNycTZQOwnnZYNmvujL8_9c9Upx3kK2RlVGifbELXY-3yW0mrWqingS7U&m=iRh6nEotbfKHFIXI9A54mn8mX9WnOFa1RLKMlXDQAjk&s=vtPzZKTG6Ju-WczYEuZ1TJP2HOV-5yvr7Kv5ajKy8gg&e=
>
> 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
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
More information about the keycloak-dev
mailing list