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://www.keycloak.org/support.html .
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://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
), 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://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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev