Kerberos progress
by Marek Posolda
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
10 years, 12 months
apps access to and refresh of facebook tokens
by Bill Burke
At least for openid connect, I think we hashed this through on our dev
call today.
* There will be a Protocol Claim Mapper that can add a facebook token
and expiration claim to the application's access token.
* the refreshToken endpoint will accept a "scope" parameter. The
application can then request the refresh of any external token by
specifying this token in the "scope parameter.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
Internationalization for model data
by Bill Burke
There's data stored in a bunch of places that should be
internationalized. i.e. Role descriptions. I was thinking for this
type of stuff, for both simplicity and ease of migration, we still
continue to input this type of metadata through one field. Then if the
user wants to internationalize a piece of data, they just replace the
text with a property variable.
Role Description: "Admin access to main application"
could be replaced with
Role Description: "${role.admin.description}"
Then the variable 'role.admin.description' is just replaced with a
theme-based property.
This way, users dont' have to learn about internationalization until
when and if the need it, existing deployments will still just work, and
we don't have to expand our data model.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
Json Web Encrpytion
by Jae Choi
Is there going to be some JSON web encryption support for Keycloak JWT?
--
Kind Regards,
Jae Choi
11 years
Re: [keycloak-dev] Keycloak Clustering 1.1.0.Final - Getting infinispan type casting error (DefaultCacheContainer to EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory
by Bappaditya Gorai (bgorai)
In my standalone configuration file I am using following subsystem version for infinispan, not sure whether it has any relevance to my issue.
<subsystem xmlns="urn:jboss:domain:infinispan:1.5">
Thanks
Bappaditya Gorai
From: Bappaditya Gorai (bgorai)
Sent: Monday, February 23, 2015 2:46 PM
To: keycloak-dev(a)lists.jboss.org
Subject: Keycloak Clustering 1.1.0.Final - Getting infinispan type casting error (DefaultCacheContainer to EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory
Hi Team,
I am trying configure Keycloak in clustered environment (EAP 6.3), however getting following error (stack trace is provided below) . I have followed instructions provided in "Chapter 24. Clustering" in Keycloak Guide (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering...). Let me know if I am missing something.
13:23:25,681 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] (ServerService Thread Pool -- 62) JBWEB000289: Servlet Keycloak REST Interface threw load() exception: java.lang.ClassCastException: org.jboss.as.clustering.infinispan.DefaultCacheContainer cannot be cast to org.infinispan.manager.EmbeddedCacheManager
at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.initContainerManaged(DefaultInfinispanConnectionProviderFactory.java:70) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.lazyInit(DefaultInfinispanConnectionProviderFactory.java:59) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:30) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:18) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
Thanks
Bappaditya Gorai
11 years
Re: [keycloak-dev] Internationalization for model data
by Michael Gerber
The definition in the message property file should be like this.
invalidPassword.minlength.message=Invalid password: must contain at least {0}
The current password validation for example returns messages like this:
return count < min ? "Invalid password: must contain at least " + min + " numerical digits" : null;
I can't replace this with a single key, because of the variable min.
However, I can replace the return type with an object which contains the message key and their parameters or a string lilke ${invalidPassword.minlength.message:min} or something similar.
I think there are other places where we need a possibility to internationalize a message with variables.
Am 26. Februar 2015 um 07:17 schrieb Stian Thorgersen <stian(a)redhat.com>:
I'm concerned that allowing any variable in any message would result in horrible performance. We'd have to use FreeMarker or something else to template each individual message, and it couldn't be cached either as the variables change. Would doing it on a case-by-case basic be enough?
For example:
invalidPassword.minlength.message=Invalid password: must contain at least {0}
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Michael Gerber" <gerbermichi(a)me.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, February 25, 2015 9:30:45 PM
Subject: Re: [keycloak-dev] Internationalization for model data
invalidPassword.minlength.message=Invalid password: must contain at
least ${realm.passwordpolicy.minLength}
Would need a way to resolve non message property properties.
On 2/25/2015 2:21 PM, Michael Gerber wrote:
> How do we want to internationalize messages which contains variables like:
> „Invalid password: must contain at least „ + min + " upper case characters"
>
> ${invalidPassword.minLength} This doesn’t work.
>
>
>> Am 24.02.2015 um 14:44 schrieb Bill Burke <bburke(a)redhat.com>:
>>
>> There's data stored in a bunch of places that should be
>> internationalized. i.e. Role descriptions. I was thinking for this
>> type of stuff, for both simplicity and ease of migration, we still
>> continue to input this type of metadata through one field. Then if the
>> user wants to internationalize a piece of data, they just replace the
>> text with a property variable.
>>
>> Role Description: "Admin access to main application"
>>
>> could be replaced with
>>
>> Role Description: "${role.admin.description}"
>>
>> Then the variable 'role.admin.description' is just replaced with a
>> theme-based property.
>>
>> This way, users dont' have to learn about internationalization until
>> when and if the need it, existing deployments will still just work, and
>> we don't have to expand our data model.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> 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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11 years
