[keycloak-user] SPNEGO with Keycloak

[Bill Burke]

On 10/13/2014 11:35 AM, Raghuram wrote:
>
>
> Sent from my iPhone
>
>> On Oct 13, 2014, at 10:30 AM, Bill Burke <bburke at redhat.com> 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