Removal of adapters for older containers
by Stian Thorgersen
We are going to remove support for the following containers soon:
* WildFly 8
* JBoss AS 7.1
* Jetty 8.1 and 9.1
* Tomcat 6
We've also started discussing if we can remove support for more WildFly
versions. Is anyone still using our adapters on WildFly 9, 10 or 11?
Any general comments around when we should remove support for old and no
longer maintained versions of containers would also be welcome.
8 years, 1 month
Cross-DC Replication not working for `sessions` cache
by Hayden Fuss
Hello,
We are attempting to run Keycloak on two OpenShift clusters using remote
ISPNs and a single MariaDB instance. We're hacking together the Keycloak on
Openshift blogpost, the JDG-as-a-service demo from Summit, RH SSO demo from
Summit, and following the Keycloak/RH SSO basic setup guide to Cross-DC
replication. The hope is do an initial evaluation of Keycloak's
availability.
We were able to create a new user on master (site1), disable the user on
master2 (site2), and see the user was disabled on master. So ISPN
replication seems to be working because the work cache was replicated to
invalidate the local caches. However, the sessions cache does not seem to
be replicated because when logged in as the same user on the two different
Keycloaks (in Incognito mode) there is only one active session shown on
both UIs and the timestamp/IP/etc is different for the listed session.
We are using the latest, stable Keycloak image, version 4.1.0.Final, and
the latest, stable Infinispan image for to act as our data grid, version
9.3.1.Final, which we know differs from the 8.2.8 version Keycloak uses for
its local caches.
We were trying one Keycloak node and two ISPN nodes in each cluster, but
for simplicity we've attached logs where we only ran one Keycloak and one
ISPN in each cluster.
We were connecting to the two different Keycloaks via two different
OpenShift Routes without a load balancer to fake sticky sessions for now.
Keycloak connects to ISPN via a "HotRod" Service. ISPN connects to other
nodes within the same cluster via KUBE_PING, and discovers the other
cluster via TCPPING hitting a particular OpenShift app node from that
cluster that exposes the "discovery" Service with a NodePort. The Keycloaks
share the single MariaDB through a NodePort Service in one of the clusters
as well.
The logs didn't seem to contain any of the messages in the trouble shooting
guide. We had trouble using JMX to check the ISPNs because they were
running in containers, but we've using the CLI tool and the Infinispan
management console to try to troubleshoot but any key we pulled from the
logs that we thought was a session ID was not in the caches and we could
not find a way to simply list all keys in the caches.
Below is a viewable link to a zip containing logs from the scenario
described in the second paragraph, and our config files.
https://drive.google.com/open?id=0B_OCdNCEtoCYOU12T3dEUFplS193VFNFbEFYclB...
Thanks for your time and help!
Best,
Hayden
8 years, 1 month
Does Keycloak need sticky session at the load balancer?
by Rafael Weingärtner
Hello Keycloakers,
I have some doubts regarding Keycloak and load balancers. I set up two
keycloak replicas to provide HA. To start them I am using “./standalone.sh
--server-config=standalone-ha.xml”. I am assuming that they will use
multicast to replicate information between nodes, right?
Then, I set up a load balancer layer using Apache HTTPD and AJP connector
via 8009 port. To make everything work I needed to use sticky session;
otherwise, the login would never happen. I am fine with the sticky session,
however, if I stop one of the replicas where the user is logged in, when
the user access Keycloak again, he/she is asked to present the credentials
as if he/she was not logged in the other Keycloak replica. Is that the
expected behavior?
Is there some troubleshooting or test that I can perform to check if
replication is being executed?
--
Rafael Weingärtner
8 years, 1 month
Mixing Identity Broker with Federated provider
by Ceri Coburn
Hi,
Is it possible to use Federated LDAP/AD for importing accounts but use
OAuth broker for authenticating them users?
I am importing users from local AD server which sets up the users upn
as the login name and email address. I have then setup Azure AD using
OIDC identity broker and setup a "Username Template Importer" to use
the same upn attribute from the OAuth claims so that the username and
email match that of the imported LDAP accounts.
But when I login using Azure AD, keycloak complains of an existing
username already present.
Is there a way I can have Azure AD and Federated LDAP imports work
together so that it assumes the same identity?
Thanks.
8 years, 1 month
attributes are not persisted
by Max Bruchmann
Hi,
I have a custom EventListenerProvider that consumes Register and Login events.
On register it creates some external resource
...//on register
String externalID = createSomethingWithUserEmail(userModel.getEmail())
userModel.setSingleAttribute("foo", externalID)
...
On login I need to todo some additional calls with the already created id.
...// on login
String externalID = userModel.getFirstAttribute("foo");
doSomeUpdate(externalID, userModel.getFirstName(), userModel.getLastName())
...
Unfortunatelly the retrieved id via getFirstAttribute seems to be null.
Is there anything I need todo when modifying attributes so they are persisted?
Kind Regards,
Max
8 years, 1 month
Re: [keycloak-user] @SecurityDomain("keycloak") in EJB
by Ryan Slominski
Looks like @SecurityRealm("keycloak") is needed only if you have the elytron configuration in your wildfly standalone.xml file. I noticed that one test server had a bunch of extra keycloak elytron configuration while the other didn't. I deleted the extra configuration and now my application works as expected (authentication and authorization info is propagated to EJBs without any extra annotations). I guess this is the difference between legacy configuration and new elytron configuration. Seems like the new elytron client adapter is not as good as the legacy adapter / integration. Any reason not to stick with the legacy adapter?
----- Original Message -----
From: "Ryan Slominski" <ryans(a)jlab.org>
To: "keycloak-user" <keycloak-user(a)lists.jboss.org>
Sent: Wednesday, August 22, 2018 12:26:43 PM
Subject: @SecurityDomain("keycloak") in EJB
Using the Wildfly adapter I've noticed that the security context is propagated to EJBs without the SecurityDomain annotation in some cases, but not others. Does anyone know in what case it is needed? My only clue so far is Windows vs Linux, as I thought I configured both test boxes identically, but maybe I missed something. My application currently does not use the annotation and on my Windows test box authentication is propagated fine. However, on my Linux test box with the same war file I see unauthorized exception in the EJB layer even though the servlet reports I'm authenticated with proper roles. Does it have to do with Wildfly client adapter online vs offline install or adapter vs adapter-elytron install?
If I end up having to import the org.jboss.ejb3.annotation.SecurityDomain that would break platform independence, which container managed security is supposed to support.
8 years, 1 month
servlet filter (KeycloakOIDCFilter) not working 4.0.0
by Nhut Thai Le
Hello,
I compiled the oidc servlet-filter then wrap both the servlet-filter and
the servlet-adapter-spi jar in an osgi bundle (attached) in order to use
them in our osgi env. Here is the code:
Dictionary<String, Object> filterProps = new Hashtable<String, Object>();
String[] urls = { "/*" };
// String[] servlets = {"My Servlet", "Faces Servlet"};
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_NAME,
"keycloakFilter"); //$NON-NLS-1$
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATTERN,
urls);
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_INIT_PARAM_PREFIX
+ "realm", "realm1");
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_INIT_PARAM_PREFIX
+ "resource", "tenant1");
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_INIT_PARAM_PREFIX
+ "auth-server-url", "https://testa.com:8543/auth");
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_INIT_PARAM_PREFIX
+ "ssl-required", "all");
Dictionary<String, String> creds = new Hashtable<String, String>();
creds.put("secret", "this is not a secret");
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_INIT_PARAM_PREFIX
+ "credentials", creds);
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_INIT_PARAM_PREFIX
+ "use-resource-role-mappings", "true");
filterProps.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_INIT_PARAM_PREFIX
+ "disable-trust-manager", "true");
// filterProps.put("servletNames", servlets);
keycloakFilter = context.registerService(Filter.class,
new KeycloakOIDCFilter(), filterProps);
When I start equinox, i see the bundle get activated but going to the
protected url (here is /) i got 403 instead of a redirect to keycloak login
page.
The code above is inspired from
the
KC
documentation "The Keycloak filter has the same configuration parameters as
the other adapters except you must define them as filter init params
instead of context params "(
https://www.keycloak.org/docs/latest/securing_apps/index.html#_servlet_fi...
)
, and the example of registering servlet filter using whiteboard pattern on
pax-web (
https://github.com/ops4j/org.ops4j.pax.web/blob/master/samples/whiteboard...).
Therefore i'm not sure the problem is on keycloak (bad bundle, wrong
configuration supplied to the filter) or pax-web (wrong registration
syntax). Hope to get some insight here
Thai
8 years, 1 month
@SecurityDomain("keycloak") in EJB
by Ryan Slominski
Using the Wildfly adapter I've noticed that the security context is propagated to EJBs without the SecurityDomain annotation in some cases, but not others. Does anyone know in what case it is needed? My only clue so far is Windows vs Linux, as I thought I configured both test boxes identically, but maybe I missed something. My application currently does not use the annotation and on my Windows test box authentication is propagated fine. However, on my Linux test box with the same war file I see unauthorized exception in the EJB layer even though the servlet reports I'm authenticated with proper roles. Does it have to do with Wildfly client adapter online vs offline install or adapter vs adapter-elytron install?
If I end up having to import the org.jboss.ejb3.annotation.SecurityDomain that would break platform independence, which container managed security is supposed to support.
8 years, 1 month
