1:38 a.m.
Hi all,
I’ve been going through new Keycloak use case and ran into situation where I am not
certain which SPI or API to use. First of all, I would like users to not have any
passwords and don't see Keycloak by most of time. I already confirmed that such state
can be achieved with extra parameters for authorisation and identity brokering links which
is great.
Second part of scenario goes as follow:
1. I have external IdP which I trust entirely, let say google.
2. I don’t want to store user accounts - google does it well.
3. Keycloak is token mapper with possibility to store extra attributes.
4. Any personal information should be pseudo-anonymised (GDPR)
5. It would be great if I could log in user automatically with provider token sent to my
service.
I wen’t over developer docs and administration too. There is a paragraph about user
federation and storage and few sentences about importing users. Based on these I can not
really determine which one should I follow. I do not want to import users as there might
be quite a lot of them. Copying entire profile information will occupy a lot of space and
require syncing which I do not really want to do.
Assuming that I will manage to get user federation (with no import) based on social broker
login, will it be abuse of keycloak abilities? Will keycloak behave properly, if I will
mock him down in a way that when identity broker asks about federated account - it will
always get copy of its own data back?
I found some points to use custom Authenticator, however I am not sure if it’s gonna fly
as I haven’t found any confirmation that such way will actually work.
Kind regards,
Łukasz
—
Code-House
http://code-house.org
11:59 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I went through code, found a "RealmBean.isPassword" method and after
few moments of sniffing managed to find solution. It is necessary to
disable username password form in browser flow.
By disabling username password form and having Identity Provider
Redirector in place pinned to my favorite service I get automatic
redirect to external IdP. What is interesting - leaving unconfigured
IdP redirector caused troubles.
Second part of process is still relevant and big mistery - how to
avoid creation of account in keycloak and how to make
pseudo-anonymisation.
Best regards,
Łukasz
- --
Code-House
http://code-house.org
On 08.02.2019 01:38, luke(a)code-house.org wrote:
Hi all, I’ve been going through new Keycloak use case and ran into
situation where I am not certain which SPI or API to use. First of
all, I would like users to not have any passwords and don't see
Keycloak by most of time. I already confirmed that such state can
be achieved with extra parameters for authorisation and identity
brokering links which is great.
Second part of scenario goes as follow: 1. I have external IdP
which I trust entirely, let say google. 2. I don’t want to store
user accounts - google does it well. 3. Keycloak is token mapper
with possibility to store extra attributes. 4. Any personal
information should be pseudo-anonymised (GDPR) 5. It would be great
if I could log in user automatically with provider token sent to my
service.
I wen’t over developer docs and administration too. There is a
paragraph about user federation and storage and few sentences about
importing users. Based on these I can not really determine which
one should I follow. I do not want to import users as there might
be quite a lot of them. Copying entire profile information will
occupy a lot of space and require syncing which I do not really
want to do.
Assuming that I will manage to get user federation (with no import)
based on social broker login, will it be abuse of keycloak
abilities? Will keycloak behave properly, if I will mock him down
in a way that when identity broker asks about federated account -
it will always get copy of its own data back? I found some points
to use custom Authenticator, however I am not sure if it’s gonna
fly as I haven’t found any confirmation that such way will actually
work.
Kind regards, Łukasz — Code-House http://code-house.org
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEADg9iP9JyIvtOw5OAdrcj4PeJmUFAlxdYP8ACgkQAdrcj4Pe
JmW5Xg/9H8gevRuEtoWkaN/TkURpxcdcq6LC7DG55IC2zCVzqkb2GvCluRiJ12Kp
DhkX/ge7mr9RRhqfMDd6TmGZYr5eb4PGEFjZSOdkcfRhd2eur6AL60lb/8scLoGI
+8CNJRTOLYNwwCn6XKS9hc6dDuWP+Qp05xktH/nYCu/OE1eq3xZA0e7a5oCKLTzY
+edYuopjAYUpBf8kJEzl6efwmEH5rNyv6L0MYBIDZRLhdIOsAWLXCMCZ/fN7VjNj
Yn38yEDhYqFY7ldGBQBmgsYTykqw0umFiiS2imksCBN1R6D0VbQtPf329XfU6jkM
yWAngySNVIP7DkRW6m+zLeGeu9tW+JUcbl5h+xpfhFadGIIAcc9YkJmdB0dZ3ucp
B+fExtoE4Zb0QGaZr3UbIlHhpYWOLWeImJFnph9aEXdDpmaE/4OQlmzBnPf/eT0R
1wWV4UUPBEco1G9NUSR+bqkX4evaZcVcW2bu1PmnJ28E5rZm/drlMh7EG0tF6TeO
Y7Up1fOBKDaj1Y73Zr1v7yZIAdF3EVCJFV/FcV5lfKcmN/D3rOu0bsJTwTUKNs9I
5cGCclxR9jA06WQa1uuzzAyf86MzRqYek64f+kEMkjf2voNYPvRYbw6nU9Z+4l9c
ERVLuMg8mY5MoMhoNdxaj2WcLmZcDL7zMzs3P9g0jWDDHcbiOiE=
=1Y8v
-----END PGP SIGNATURE-----
2177
days inactive
2177
days old
1 comments
2 participants
participants (2)
-
luke＠code-house.org -
Łukasz Dywicki