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