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> 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