[keycloak-user] SPNEGO with Keycloak

[prab rrrr]

Great. Thanks Bill. Deviating from the topic a bit, I found the below websites very useful in understanding spnego/Kerberos authentication.

How to obtain and authenticate Kerberos and SPNEGO tokens with JGSS
https://github.com/spring-projects/spring-security-kerberos
 


On Monday, October 13, 2014 5:57 PM, Travis De Silva <traviskds at gmail.com> wrote:
  


great discussion. Now its up to Bill and the cool Keycloak folks to schedule this in one of their planned releases. Bill any idea which release this might get implemented?



On Tue, Oct 14, 2014 at 3:30 AM, Bill Burke <bburke at redhat.com> wrote:


>
>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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141013/8187a215/attachment-0001.html