We can do anything we want on the server side, the problem is that our
client adapters, SAML and OIDC, should be able to work with non-Keycloak
On 9/15/2015 7:25 AM, Stian Thorgersen wrote:
> Could we store the mapping on the Keycloak side? client-id + http
> session id --> KC session id?
> On 14 September 2015 at 22:41, Bill Burke <bburke(a)redhat.com
> <mailto:email@example.com>> wrote:
> On 9/14/2015 4:20 PM, Marek Posolda wrote:
> > On 14/09/15 21:46, Bill Burke wrote:
> >> The SAML IdP is not required to send back that id. That ID is just
> >> the ID of the request.
> > The SAML IdP doesn't need to send anything back. I meant that
> > HttpSessionID will be send in the ID of SAMLRequest from SAML SP to
> > auth-server . I don't know if there is any better attribute/element of
> > AuthnRequest, which can be used to transmit such "custom" data.
> SAML logout requests to the SP client contain the principal name and/or
> possibly one *or more* SSO IDs (session indexes). New OIDC spec will
> work similarly.
> >> A hack I'm thinking of is to create an HttpSession that is shared by
> >> everybody and store this SSO id/username -> to -> HttpSession id map
> >> there.
> > That's good, we can avoid dependency on infinispan.
> Ugh, unfortunately, you can't provide our own session id with Undertow's
> or Jetty's sessionmanager interface. :( So no way to hack this except
> for Tomcat and JbossWeb.
> > But still, we will
> > need the stuff like periodic cleaner thread, which will remove expired
> > items from this HttpSession map. And this solution requires HttpSession
> > replication if I understand correctly?
> Replication would be required, but all these servlet containers contain
> session lifecycle listener SPIs, so there is no need for reaper threads.
> But, can't do it anyways...
> > As of now, we don't require HttpSession replication for OIDC. Qe support
> > the deployments when the application is deployed on more "cluster" nodes
> > behind loadbalancer, but application cluster nodes don't communicate
> > with each other. In other words, there is no "distributable" in web.xml
> > . For this case, we have CLIENT_SESSION_HOST note, so the OIDC
> > backchannel request is sent to same cluster node from which was
> > code-to-token request sent earlier.
> Again, not something we can implement in a standard/portable way.
> Bill Burke
> JBoss, a division of Red Hat
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:firstname.lastname@example.org>
JBoss, a division of Red Hat
There's two things you can do:
1. You can pass the users locale to Keycloak with the ui_locales param when
the user logs in
2. Add the locale to the token with a mapper so your application can read
what locale the user has selected in Keycloak
On 15 September 2015 at 13:46, Tair Sabirgaliev <tair.sabirgaliev(a)bee.kz>
> Is it possible to reuse the user account language settings across sso
> domain? That is an important use case for my project?
> On Вт, 15 сент. 2015 г. at 17:36 Lennart Jörelid <
> lennart.jorelid(a)gmail.com> wrote:
>> That is - in itself - a problem for an application with
>> works-out-of-the-Box aspirations, yes?
>> // vänlig hälsning,
>> // [sw: "best regards"],
>> // Lennart Jörelid
>> 15 sep 2015 kl. 13:29 skrev Stian Thorgersen <sthorger(a)redhat.com>:
>> Why would we need i18n/l10n for examples? We don't provide
>> internationalization of applications themselves.
>> On 15 September 2015 at 10:02, Boleslaw Dawidowicz <bdawidow(a)redhat.com>
>>> I would rather keep them simple.
>>> We would consider a single bigger and more complex one - then it would
>>> On Mon, Sep 14, 2015 at 5:40 PM, Stan Silvert <ssilvert(a)redhat.com>
>>> > Wondering...
>>> > Will we need to do i18n/l10n for the examples?
>>> > Do we want to upgrade angular for the examples that us it? Right now,
>>> > they are still using AngularJS 1.2 while the admin console uses 1.4.
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> Bolesław Dawidowicz
>>> keycloak-dev mailing list
>> keycloak-dev mailing list
>> keycloak-dev mailing list
I'm working with jboss wildfly 9. I have a provider deployed as module into the modules directory.Then i have a jpa project with DAO pattern writing and reading inside my database. I want to handle the DAO transaction using JTA but in order to make the DAO class visibile to myprovider i need to put the DAO JPA project inside the modules directory too.Now i m facing the real problem: it seems i cannot use the PersistenceContext annotation to inject the entity manager into my EntityManager variable wich is always null. Why i cannot inject the a context into a jar modules? What am i wrong?
I'm working with jboss wildfly 9. I have a provider deployed as module into the :
wildfly > modules > com > mycompany > myprovider
folder. Then i have a jpa project with DAO pattern writing and reading inside my database. I want to handle the DAO transaction using JTA but in order to make the DAO class visibile to myprovider i need to put the DAO JPA project inside the modules directory too.
Now face the real problem: it seems i cannot use the @PersistenceContext annotation to inject the entity managare into my EntityManager varible:
@PersistenceContext(unitName = "KAS-Mapping") private EntityManager entityManager;
this is my persistence.xml
<persistence version="2.1" ...> <persistence-unit name="KAS-Mapping"> <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider> <class>my.class.persistence.model.MapGroup</class> <clas>my.class.persistence.model.MapUser</class> <properties> <property name="javax.persistence.provider" value="org.hibernate.ejb.HibernatePersistence" /> <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect"/> <property name="javax.persistence.provider" value="org.hibernate.jpa.HibernatePersistenceProvider"/> <property name="javax.persistence.transactionType" value="JTA"/> <property name="javax.persistence.jtaDataSource" value="java:jboss/datasources/MyDS"/>
</properties> </persistence-unit> </persistence>
Why i cannot inject the a context into a jar modules? What am i wrong?
I'm running into a problem implementing backchannel logout for our new
SAML SP. SAML has no way of transmitting client specific session
information that I can tell. So, I need some way of associating an
auth-server specific session index and the Principal so that I can look
up an Http Session and invalidate it based on one of those parameters.
We're gonna have the same exact problems when we implement the OIDC
equivalent specifics (these are new BTW).
I'm thinking of writing a simple Infinispan cache that associates
principals/session-indexes to http session ids and have it reusable
between SAML and OIDC adapters.
JBoss, a division of Red Hat
With Active Directory, a user is required to change their password on next login if the pwdLastSet attribute on their account is set to zero. It would be nice to redirect the user to a form where they can change their password if they try to login under this scenario. On Keycloak 1.4 it seems that the application currently just displays a login error when this is the case. Any thoughts on this or can I go ahead and create an issue and try to implement this change?