4:06 p.m.
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
4:11 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:24 p.m.
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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
7:53 a.m.
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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:54 a.m.
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(a)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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com/
9:29 a.m.
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(a)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(a)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(a)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(a)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
10:10 a.m.
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(a)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(a)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(a)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(a)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(a)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
10:29 a.m.
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(a)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(a)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(a)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(a)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(a)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/>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:43 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)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/>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
7:36 a.m.
JBoss/Wildfly has had SPNEGO/Kerberos support for I think like 8-9
years? This is the original project:
https://developer.jboss.org/wiki/JBossNegotiation
I 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(a)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(a)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(a)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(a)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(a)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(a)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/>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)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
9:15 a.m.
Bill - To your Point No 2) - Why limit Keycloak to be a bridge to just Kerberos Server?
Extending it to other mechanisms like Radius/SecurID and providing support for Multi
factor authentication would make Keycloak a true Federation product.
Travis - As you pointed out, SPNEGO support is major requirement and even I am not clear
how to make it happen. If you have other requirements then perhaps the Federation API in
Keycloak can be used to make it a bridge to other authentications like SecureID and MIT
Kerebros.
On Sunday, October 12, 2014 8:36 AM, Bill Burke <bburke(a)redhat.com> wrote:
JBoss/Wildfly has had SPNEGO/Kerberos support for I think like 8-9
years? This is the original project:
https://developer.jboss.org/wiki/JBossNegotiation
I 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(a)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(a)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(a)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(a)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(a)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(a)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/>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)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
7:53 p.m.
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.
Also not sure why our application servers need to talk SAML or OpenID
Connect. If JBoss/Wildfly has support for Spengo.
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.
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.
Not sure if what I am saying makes sense as I am also not an except in
Spengo but just thought of throwing this idea out there.
Prab - Thanks for pointing out the Federation API. Will have a look to see
if this can do what I indicated above.
On Mon, Oct 13, 2014 at 1:15 AM, prab rrrr <prabhalar(a)yahoo.com> wrote:
Bill - To your Point No 2) - Why limit Keycloak to be a bridge to
just
Kerberos Server? Extending it to other mechanisms like Radius/SecurID and
providing support for Multi factor authentication would make Keycloak a
true Federation product.
Travis - As you pointed out, SPNEGO support is major requirement and even
I am not clear how to make it happen. If you have other requirements then
perhaps the Federation API in Keycloak can be used to make it a bridge to
other authentications like SecureID and MIT Kerebros.
On Sunday, October 12, 2014 8:36 AM, Bill Burke <bburke(a)redhat.com>
wrote:
JBoss/Wildfly has had SPNEGO/Kerberos support for I think like 8-9
years? This is the original project:
https://developer.jboss.org/wiki/JBossNegotiation
I 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(a)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(a)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(a)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(a)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(a)lists.jboss.org <mailto:
keycloak-user(a)lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org <mailto:
keycloak-user(a)lists.jboss.org>>
> > <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org <mailto:
keycloak-user(a)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(a)lists.jboss.org <mailto:
keycloak-user(a)lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org <mailto:
keycloak-user(a)lists.jboss.org>>
> > <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org <mailto:
keycloak-user(a)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/>
> >
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)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
9:30 a.m.
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
10:35 a.m.
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?
> 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
11:30 a.m.
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
4:57 p.m.
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(a)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(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
9:12 p.m.
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(a)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(a)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(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/
3721
days inactive
3725
days old
16 comments
4 participants
participants (4)
-
Bill Burke -
prab rrrr -
Raghuram
-
Travis De Silva