You can already delegate credential validation using our User Federation SPI. As far as pluggable auth mechanisms, we already have cert-auth and kerberos on the roadmap which would require such an SPI. IMO, there are really 2 authentication mechanisms: one requiring user input processing (passwords, otp, etc.), those that don't require user input processing (cert-auth, kerberos, SAML/OIDC based federation, etc.). There would end up being 2 SPIs for both.
On 10/13/2014 11:35 AM, Raghuram wrote:
Sent from my iPhone
On Oct 13, 2014, at 10:30 AM, Bill Burke <bburke@redhat.com> wrote:Session management with clustering on the key cloak side would be great
On 10/12/2014 8:53 PM, Travis De Silva wrote:
Bill - How about combining option 2 and 3. We use Keycloak as a bridge
between our application and Kerberos and then we also use Keycloak as a
backend identify store. The use case that I am thinking is that we use
the bridge only for SSO authentication and for authorization we can
assign users to roles in Keycloak and get all the other goodness of
Keycloak.
That works too.
Also not sure why our application servers need to talk SAML or OpenID
Connect. If JBoss/Wildfly has support for Spengo.
Depends on if your kerberos server supports session management, single log out. Again, I don't know enough about kerberos to answer that question
I am thinking of something like if we configure our application in
Keycloak as requiring Spengo, then when a request is made to our
application, Keycloak will intercept it and respond with a 401 Access
Denied, WWW-Authenticate: Negotiate response. This in turn will trigger
the browser to re-send the HTTP GET request + the Negotiate SPNEGO Token
in an Authorization: Negotiate token header and Keycloak uses it to pass
it via the JBoss/Wildfly security domain.
As you can see, you don't really need to integrate all the way back to a
Kerberos server but only to JBoss/Wildfly. Yes this does not cover
all scenarios and is dependent on JBoss/Wildfly but at least this would
be a start for people who use the entire JBoss/Wildfly stack.
What you're describing, I think, is the bridge I want to build. User get's authenticated via kerberos at the Keycloak server. Application uses SAML or OpenID Connect and gets a token it can understand and use for REST invocations, etc.
Perfect. SAML and Openid connect compatibility is what even I am looking for as it will take care of current as well as future requirements. The only other feature that I would request is a hook (JAAS module?) to plugin other authentication systems like secureid in addition to SPNEGO.
Bill - how about including this request in your queue?