JBoss/Wildfly has had SPNEGO/Kerberos support for I think like 8-9
years? This is the original project:
https://developer.jboss.org/wiki/JBossNegotiationI don't know enough about it or Kerberos to know if it has single log
out too. As for Keycloak's relationship to Kerberos, I see 4 things
happening:
1) You don't use Keycloak as you already have SSO with an existing
Kerberos deployment
2) Your application servers talk SAML or OpenID Connect and Keycloak
becomes a bridge between the Kerberos server and your applications
3) You authenticate using your existing Kerberos architecture and
Keycloak becomes a back end identity store.
4) Keycloak becomes a Kerberos Server.
Due to non-technical reasons, #4 is the least likely to happen. If you
have any other ideas on integration points let me know.
On 10/11/2014 5:43 PM, Travis De Silva wrote:
> I thought with SPNEGO/Kerberos we can achieve true SSO. Most large
> organisations are on a Windows environment and what these organisations
> want is once you authenticate to the corporate desktop, you should be
> able to then also access other applications without having to go through
> the login process. wonder how we can achieve this with KeyCloak?
>
> On Sun, Oct 12, 2014 at 2:29 AM, Bill Burke <
bburke@redhat.com> <mailto:
bburke@redhat.com>> wrote:
>
> Keycloak is an IDP server. It is not an adapter project for
> JBoss/Wildfly distributions. There's already a lot of great adapters to
> integrate your JBoss/Wildfly distributions to use SPNEGO and SAML. We
> already support federation with LDAP/AD for storage and authentication,
> OpenIDConnect and SAML as our auth protocols. The only thing on the
> roadmap for Kerberos is to make Keycloak to be a Kerberos to SAML/OpenID
> Connect bridge. It could be possible to poach or merge with Apache DS
> so that Keycloak could become a full Kerberos server too, but there are
> additional non-technical obstacles from us putting this option in our
> roadmap that I'd rather not discuss.
>
> But anyways, Keycloak doesn't use JAAS login modules on the IDP server
> side. On the client side doesn't make sense either as Keycloak only
> talks OpenIDConnect and SAML (in
master).
>
> On 10/11/2014 11:10 AM, prab rrrr wrote:
> > Well, without support for external authentication, I am wondering how
> > big organizations that have already invested in Kerberos/SecurID etc,
> > would use this product? Typically, the Federation products like
> > Ping,OpenAM etc provide hooks for multiple stores to:
> > 1) Support Kerberos or SecureID or other authentication and
> retrieve the
> > user principal
> > 2) Retrieve user meta data from LDAP using that principal and
> > 3) Use the user meta data to customize the claims or userinfo.
> >
> > I was hoping to see the above features in this product, given that
> > Keycloak already supports OpenID Connect (along with support for
> CORS,
> > javascript and future support for mobile devices) and it can act
> as an
> > Identity provider (OP). Perhaps Keycloak can synchronize all the user
> > information from stores like LDAP but it would still need a hook
> to plug
> > in external authentication
> >
> > BTW I suggested realm to authetication mapping because different
> > applications in an organization have different authentication
> > requirements (some apps require SecuriID,some Kerberos etc) and those
> > applications can be mapped to the realm that uses an authentication
> > mechanism that they require.
> >
> >
> >
> > On Saturday, October 11, 2014 10:29 AM, Bill Burke
> <
bburke@redhat.com <mailto:
bburke@redhat.com>>
> > wrote:
> >
> >
> > What you describe would work only if you treat Keycloak solely as an
>
> identity store and wrote a login module that uses Keycloak admin
> > interface to obtain principal and role mapping information. Then there
> > is the issue of getting the Kerberos server and Keycloak using the same
> > user database. Then for this particular idea, you start to wonder if
> > using Keycloak is any benefit.
> >
> > On 10/11/2014 9:54 AM, prab rrrr wrote:
> > > Wildfly makes a number of login modules available as a part of the
> > > Security sub system that include SPNEGO (see the
link below). Since
> > > Keycloak supports defining new Realms, if you can provide some hooks to
> > > map the newly defined Realms to the Security sub system, I think it
> > > would address the issue. Picketlink examples shed some light on how it
> > > can be done.
> > >
> > >
> >
https://docs.jboss.org/author/display/WFLY8/Security+subsystem+configuration> > >
> > >
> > > On Saturday, October 11, 2014 8:53 AM, Bill Burke <
bburke@redhat.com <mailto:
bburke@redhat.com>
> > <mailto:
bburke@redhat.com <mailto:
bburke@redhat.com>>> wrote:
> > >
>
> >
> > > Kerberos is on our roadmap as there's some other Red Hat kerberos
> > > products we need to integrate wit. I don't understand Kerberos deep
> > > enough yet to know exactly what or how we would do it. My current
> > > thought that the Keycloak auth server would be a secured Kerberos
> > > service and become a bridge between kerberos and SAML or OpenID Connect.
> > >
> > > On 10/10/2014 5:24 PM, Raghuram wrote:
> > >
> Can I put in an enhancement request for at least some hooks as I am
> > > not sure how a custom federation provider could be written for SPNEGO
> > > negotiation. This feature will be useful for all organizations that
> > > invested in Kerberos infrastructure.
> > > >
> > > >> On Oct 10, 2014, at 5:11 PM, Bill Burke <
bburke@redhat.com <mailto:
bburke@redhat.com>
> > <mailto:
bburke@redhat.com <mailto:
bburke@redhat.com>>
> > > <mailto:
bburke@redhat.com <mailto:
bburke@redhat.com>
> <mailto:
bburke@redhat.com <mailto:
bburke@redhat.com>>>> wrote:
> > > >>
> > > >> we don't support kerberos.
> > > >>
> > > >>> On 10/10/2014 5:06 PM, Raghuram wrote:
> > > >>>
> > > >>>> Has anyone tried out SPNEGO (Kerberos) authentication with key
> > cloak
> > > >>>> 1.0.2? If so, appreciate any input on how it can be achieved?
>
> > >>>
> > > >>> Sent from my iPhone
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> keycloak-user mailing list
> > > >>>
keycloak-user@lists.jboss.org <mailto:
keycloak-user@lists.jboss.org>
> > <mailto:
keycloak-user@lists.jboss.org <mailto:
keycloak-user@lists.jboss.org>>
> > <mailto:
keycloak-user@lists.jboss.org> <mailto:
keycloak-user@lists.jboss.org>
>
> <mailto:
keycloak-user@lists.jboss.org <mailto:
keycloak-user@lists.jboss.org>>>
> > > >>>
https://lists.jboss.org/mailman/listinfo/keycloak-user> > > >>
> > > >> --
> > > >> Bill Burke
> > > >>
JBoss, a division of Red Hat
> > > >>
http://bill.burkecentral.com/> > >
> > > >> _______________________________________________
> > > >> keycloak-user mailing list
> > > >>
keycloak-user@lists.jboss.org <mailto:
keycloak-user@lists.jboss.org>
> > <mailto:
keycloak-user@lists.jboss.org <mailto:
keycloak-user@lists.jboss.org>>
> > <mailto:
keycloak-user@lists.jboss.org> <mailto:
keycloak-user@lists.jboss.org>
> > <mailto:
keycloak-user@lists.jboss.org <mailto:
keycloak-user@lists.jboss.org>>>
> > > >>
https://lists.jboss.org/mailman/listinfo/keycloak-user> > >
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> >
>
http://bill.burkecentral.com/> > >
> > >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> >
http://bill.burkecentral.com <
http://bill.burkecentral.com/>