Re: [keycloak-user] SPNEGO with Keycloak

On 10/13/2014 11:35 AM, Raghuram wrote: > > > Sent from my iPhone > > On Oct 13, 2014, at 10:30 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: >> >> >> >> 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 >> > Session management with clustering on the key cloak side would be great > >> >> 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? > 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. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com