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.
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
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com