[keycloak-dev] questions on Marek/Hynek presentation
hmlnarik at redhat.com
Mon May 22 02:55:58 EDT 2017
On 05/19/2017 04:19 PM, Bill Burke wrote:
> * Won't the regular case be that the load balancer generates the
> affinity cookie or doesn't have a cookie at all? HA-Proxy is quite
> popular and they have both options.
> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
> What happens when the use clicks "proceed"? Does the SAML or OIDC
> request continue as normal? Or are you calculating the URI on the
> application to redirect to, if so, why?
> On Action Tokens:
> * What is the relationship between the RequiredAction SPI and
> ActionTokenHandler SPI? Does every RequiredAction have to have a
> corresponding ActionTokenHandler?
Action token can (not necessarily must) create an authentication session and among other request execution of particular required actions. Example of such an action token handler is ExecuteActionsActionTokenHandler . Ad the second question - no, required action is a different layer of execution than action token (see below).
> * Why would a app developer need to implement an ActionTokenHandler?
> Wouldn't it be better for the Required Action SPI to provide the
> appropriate metadata so that the handler could be implemented by us?
> i.e. isOneTimeToken, email-template, etc, etc. I guess what I'm saying
> is that action tokens should be incorporated into the RequiredAction SPI.
Ordinarily not. When only execution of required actions is required, a developer would use ExecuteActionsActionToken . However to initialize a run of a particular flow like in reset credentials, an action token would be the right tool rather than required action. So what I think is that the two - action tokens and required actions - are two complementary layers and should not be merged.
> * Related to above. Required actions should be able to specify an
> "admin console template" and "login template". These would be the
> freemarker template to use to create the email that is sent to the
> user. "admin console" would be from an admin generating the action.
> "login" would be when user login initiates the action email.
That makes sense and is related to required actions only, not to action tokens.
> * On the Admin Console "Credential Reset" section. Required Action
> emails (now Action tokens) aren't necessarily "Credential Resets".
> Verify email is not a credential reset. etc. This need to be renamed and
> maybe put in another tab?
+1. I've added https://issues.jboss.org/browse/KEYCLOAK-4948
> * We will need a way to offload action processing to another external
> service. keycloak exists to mark that the action was completed, but all
> the processing for the action happens in an external application. A lot
> of people have existing applications they want to integrate with that
> perform action processing. Just something to think about. We need this
> for other areas of keycloak (i.e. registration).
That would be possible with action tokens + required action: I can imagine one way of implementing this as an single-use action token (ExecuteActionsActionToken  again) that would run a required action (say ExternalRequiredAction). ExternalRequiredAction checks for presence of a potentially signed query parameter (say externalExecutionStatus).
* If the externalExecutionStatus is not set, the required action handler redirects to the respective application
* If the externalExecutionStatus is set and valid, the required action handler states context.success().
In this, the ExternalRequiredAction behaves similarly to e.g. VerifyEmail . The application has to redirect back to the same action token link with added externalExecutionStatus parameter to ensure that the action token expires. The link can be generated before redirecting to the app in ExternalRequiredAction and passed to the application.
There are certainly more sophisticated solutions to this than this one above but I hope it illustrates the idea how the action tokens and required action can interact.
More information about the keycloak-dev