[keycloak-dev] client requested account linking

[Mark Pardijs]

We are currently implementing a similar feature, slightly different but maybe it helps:

Users are logging in via SAML IdP initiated SSO request, and if their realm has configured other IdPs, we are showing a page where they can log in to the other IdPs so in the end the Keycloak account is linked to the two external IdPs. 

We’ve managed to do this with custom first/post broker login authentication flows, with a custom authenticator which shows a .ftl with the buttons you would normally see on the login screen if you have external IdPs configured. 

> Op 24 feb. 2017, om 09:21 heeft Marek Posolda <mposolda at redhat.com> het volgende geschreven:
> 
> Don't we have a plan to rewrite AccountService to use Angular+REST? If 
> yes, then we are fine though. We will have REST endpoint for link 
> broker, which can be invoked with the bearer token as long as the token 
> has "manage-account" scope. We don't need to care about CSRF then.
> 
> I can see the only reason to keep support browser+cookie based flows - 
> the case when client application doesn't have Keycloak token. But from 
> what you mentioned in the last paragraph, it looks that their client has 
> our access token?
> 
> Marek
> 
> 
> On 23/02/17 23:24, Bill Burke wrote:
>> A customer has asked us to implement a feature in which there is a
>> browser endpoint on keycloak.  This URL can be told to link to a
>> specific identity broker provider (Google, Facebook, etc.) and then the
>> browser would be redirected back to the client. Pretty much what exists
>> in the Account Service console, but without having to look at the
>> Account Service.  The reason for this is that they are doing integration
>> with a specific social provider and don't want to have to go through the
>> Account Service pages. Seems pretty reasonable and valid use case...
>> I'm worried about a couple of things:
>> 
>> * The design of it
>> 
>> * The security implications.
>> 
>> The implementation would be simple enough, it would just extract code
>> from the accoutn service.  The endpoint would take a "providerId"
>> paramter that would be the idp linking to, a "clientId" for the client
>> requesting the link, and a "redirect_uri" to redirect back to after the
>> link is successful. Obviously the redirect_uri would be validated
>> against the clientId.
>> 
>> Now comes the interesting part, the security implications. Account
>> linking in the Account Service is fine and dandy and doesn't have any
>> security holes because we guarantee that the Account Service initiated
>> the linking via a CSRF check.  For this new Client-Requested-Linking
>> feature, if we do nothing, and just model it as above, we cannot
>> guarantee that the client initiated the linking request.  What are the
>> implications of this?  This feature would be vulnerable to CSRF.  A
>> rogue website could initiate account linking to a specific configured
>> provider.  Is this bad?  I don't know.  We can guarantee that the
>> redirect uri is valid.  The browser would never get back to the rogue
>> website. So what can we do to improve this?
>> 
>> * We could do nothing and hope its ok that anybody can initiate a link.
>> 
>> * We could add a consent screen like this: "Application 'clientId' is
>> requesting that you link your user account to 'providerId'.  Do you
>> agree to this?  You will be redirected to this provider if you click
>> ok.".  This of course relies on the user to actually read the page.  Is
>> this good enough?
>> 
>> * My last thought would be OIDC specific.  We could use the POST binding
>> trick that SAML does to do a browser redirect via a POST call.  THe POST
>> would contain the access token the client has.  We match this token up
>> against the browser cookie to make sure its the same session.  We also
>> make sure that the access token has permission to request a link.  There
>> are 2 downsides to this approach a) This requires some code on the
>> client side to obtain the access token and then to package it up into an
>> HTML document so the POST binding trick can be done.  b) This will only
>> work for OIDC clients.  SAML clients will be left in the dust, although
>> I guess we could allow SAML to push a signed assertion back.
>> 
>> 
>> Thoughts?
>> 
>> 
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev