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.
BTW, there also seem to be a Jira ticket pending for Spengo support
in
WildFly.
https://issues.jboss.org/browse/WFLY-2553 So not sure if
Wildfly still has Spengo support.
Might be true. JBoss Negotiation might not have been ported to
Undertow yet.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com