On 4/8/2015 10:01 AM, Schneider, Tom wrote:
I originally proposed that we separate out the account registration
to a separate screen from the additional business data entry and hop over to keycloak for
the account registration part. This would work, however, our business analysts would
prefer to keep the user experience the same as it is today.
As far as replicating the exact same screen we have today, I would see issues with that.
We have dynamic headers, footers and side navigation functionality that would be difficult
to implement in keycloak. This is also part of a larger flow so we would need to be able
to handle forward/back navigation buttons. There is also quite a bit of additional data
that we capture, so I could see future maintenance being an issue if we had to update
keycloak every time we wanted to make changes. It's a good thought, but unfortunately
I think our page is too complex for that.
One thought I had was utilizing the new identity broker functionality for this. Our app
would be setup as both a SAML service provider and a SAML brokered identity provider. Our
app would send a SAML response to keycloak as the identity provider, keycloak would create
a SSO session for that user and then send the user back to our app with a keycloak SAML
response. Not quite the standard use case for this feature, but any thoughts on if this
might work?
Yes, using a broker could work if the registration link was on the
Keycloak login page. I guess in this case Keycloak would need a
"lightweight" IDP implementation to use in this scenario. Otherwise you
guys will be implementing a lot of crap protocol stuff.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com