[keycloak-dev] Kerberos progress

[Pedro Igor Silva]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, February 12, 2015 11:49:05 AM
> Subject: Re: [keycloak-dev] Kerberos progress
> 
> I'm just trying to figure out where does the Broker SPI end and the User
> Federation SPI begin?  And wondering if our SPIs can be unified,
> simplified, or refactored.  For example, how would client-cert auth be
> implemented?  Like Kerberos, its a credential that is checked prior to
> displaying a login screen.
> 
> Another thing, does the broker SPI allow you to still require extra
> credentials supplied by Keycloak instead of the brokered IDP?

What is the use case ?

> 
> We just have to make these SPIs intuitive enough so that users know what
> they need to do and simple enough to extend Keycloak.
> 
> On 2/12/2015 3:49 AM, Marek Posolda wrote:
> > On 11.2.2015 21:38, Bill Burke wrote:
> >> I am not understanding how you have implemented this.  Wouldn't kerberos
> >> just be an authentication mechanism that the auth server uses?  I don't
> >> understand why you would want special configuration at the adapter
> >> level.  This should all be configured at the auth server so that the
> >> application doesn't have to know if kerberos is used or not.
> > Yeah, ok. I've mentioned the option #3 (Adding parameter to adapter
> > config) just for case if you guys think that this is a way to go. But I
> > don't like much as well ;-)
> >>
> >> Wouldn't it be:
> >>
> >> 1. App does regular SAML or OIDC redirect to auth server
> >> 2. Auth server checks to see if realm supports kerberos
> >> 3. Sends 401 + HTML
> >> 4. Browser sends back ticket
> >> 5. Auth server verifies ticket, creates SAML or OIDC response and
> >> redirects browser back to application
> > Sure, that's exactly what I am doing. Application uses just SAML or OIDC
> > for communication with auth-server. It doesn't know how it is
> > authenticated. Existing brokering mechanism handles this very well and
> > that's why I am using it.
> >
> > Only thing in your flow, which I don't yet have, is step 2. Currently
> > login screen is always displayed and user needs to click on "Login with
> > Kerberos" . Addressing it is what I am asking about.
> >
> > I can either do it automatically (realm will always use kerberos broker
> > when it is available) or allow to configure it (Redirect automatically
> > to kerberos just when it's configured as default broker). I think that
> > allowing to configure is better way as it allows more flexibility.
> >
> > Marek
> >>
> >>
> >>
> >> On 2/11/2015 2:29 PM, Marek Posolda wrote:
> >>> I've already pushed initial version of Kerberos broker. It uses existing
> >>> brokering mechanism from Pedro and allows to login users to KC with
> >>> SPNEGO/Kerberos token. There are still things I need to address (more
> >>> testing + automated testing, Credentials delegation etc).
> >>>
> >>> I have a question about automatic Kerberos login without displaying
> >>> login form. Browsers support this very well - when server returns
> >>> response with status 401, header "WWW-Authenticate: Negotiate" and HTML
> >>> with login page, browsers are able to handle it and:
> >>>
> >>> * In case that user has Kerberos ticket, browser will send it back in
> >>> additional HTTP request with "Authorization: Negotiate <ticket>" . In
> >>> this case login form is not displayed to user
> >>>
> >>> * In case that user hasn't Kerberos ticket, browser just displays HTML
> >>> with login form
> >>>
> >>> You can try https://saml.redhat.com/idp/ to see what I mean.
> >>>
> >>> JBoss Negotiation supports this, so I believe we should address it too.
> >>>
> >>>
> >>> I have some ideas how to do it:
> >>>
> >>> 1) Configure default broker on server side per-realm. If used, login
> >>> request will automatically redirect to configured broker. It may be also
> >>> possible to override default broker per client?
> >>>
> >>> 2) Add on/off switch to broker configuration to specify if it should be
> >>> default or not
> >>>
> >>> 3) Leverage existing "k_idp_hint" parameter. I am thinking about adding
> >>> option "idp_hint" into AdapterConfig . In case it's configured, adapter
> >>> will use it for attach "k_idp_hint" parameter to login request. This
> >>> will allow per-application configuration and no changes on auth-server
> >>> side, but all applications will need to use it in their adapter
> >>> configuration.
> >>>
> >>> 4) Don't configure anything, but hard-code that Kerberos will be always
> >>> used by default if configured. Basically add new method "boolean
> >>> isDefault()" to IDentityProvider interface. It will return "true" for
> >>> Kerberos impl and "false" for other broker types we currently have.
> >>>
> >>> I like (1) or (2) most. Thoughts?
> >>>
> >>> Marek
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>