Re: [keycloak-user] Password less keycloak with OIDC Federation

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-----