How to add a custom Identity Provider (OIDC) mapper - keycloak

I wrote my own custom token mapper to map all roles assigned per group to a user, to the access token as a single claim that is a mapping (object) from group name to roles-list.
However I can't seem to get it deployed. This is my custom mapper:
public class HierarchicalAttributesMapper extends AbstractOIDCProtocolMapper
implements OIDCAccessTokenMapper, OIDCIDTokenMapper, UserInfoTokenMapper {...}
It is based on the GroupMembershipMapper. I added the following file in the top-level of the compiled jar:
META-INF/services/org.keycloak.broker.provider.IdentityProviderMapper
With the FQN of my HierarchicalAttributesMapper. When running my docker container for keycloak, mounting to the /opt/jboss/standalone/deployments folder it gets recognized, but then throws this warning:
[org.jboss.modules] (ServerService Thread Pool -- 58) Failed to define class
technology.idlab.cot.keycloak.oidc.HierarchicalAttributesMapper in Module
"deployment.keycloak-oidc-hierarchical-attributes-mapper-1.0-SNAPSHOT.jar"
from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link
technology/idlab/cot/keycloak/oidc/HierarchicalAttributesMapper (Module
"deployment.keycloak-oidc-hierarchical-attributes-mapper-1.0-SNAPSHOT.jar"
from Service Module Loader):
org/keycloak/protocol/oidc/mappers/OIDCAccessTokenMapper
(stack-trace omitted)
Does anyone have any idea how I can get this to work?

Related

Spring Boot Geode Unsatisfied dependency expressed through method 'sessionRegion'

The correct dependencies for my gradle.build are driving me crazy!
In order to access an Apache Geode 1.10 server, I am using:
// Geode client dependency
implementation 'org.springframework.geode:spring-geode-starter:1.2.13.RELEASE'
implementation 'org.springframework.data:spring-data-geode:2.2.12.RELEASE'
implementation 'org.springframework.boot:spring-boot-starter-tomcat:2.2.13.RELEASE'
This fails with the error:
org.springframework.context.support.AbstractApplicationContext 596 refresh:
Exception encountered during context initialization - cancelling refresh attempt:
org.springframework.beans.factory.UnsatisfiedDependencyException:
Error creating bean with name 'ClusteredSpringSessions' defined in class path resource
[org/springframework/session/data/gemfire/config/annotation/web/http/GemFireHttpSessionConfiguration.class]:
Unsatisfied dependency expressed through method 'sessionRegion' parameter 0;
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.data.gemfire.config.annotation.ClientCacheConfiguration':
Initialization of bean failed; nested exception is java.lang.IllegalAccessError:
class org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$703/0x0000000801025d10
tried to access protected method 'boolean org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport.hasValue(java.lang.Number)'
(org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$703/0x0000000801025d10
and org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport are in unnamed module of loader 'app')
What is there to tell me the dependency missing for the UnsatisfiedDependencyException for 'ClusteredSpringSessions'?
If I remove the #EnableGemFireHttpSession annotation then I get the error
2021-02-02T19:29:49,011 WARN [main] org.springframework.context.support.AbstractApplicationContext 596 refresh:
Exception encountered during context initialization - cancelling refresh attempt:
org.springframework.beans.factory.UnsatisfiedDependencyException:
Error creating bean with name 'cacheManager' defined in class path resource [org/springframework/data/gemfire/cache/config/GemfireCachingConfiguration.class]:
Unsatisfied dependency expressed through method 'cacheManager' parameter 0;
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.data.gemfire.config.annotation.ClientCacheConfiguration':
Initialization of bean failed; nested exception is java.lang.IllegalAccessError:
class org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$679/0x00000008010306b8
tried to access protected method 'boolean org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport.hasValue(java.lang.Number)'
(org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$679/0x00000008010306b8
and org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport are in unnamed module of loader 'app')
What is there to tell me the dependency missing for the UnsatisfiedDependencyException for 'cacheManager'?
Thanks
UPDATE The App is run like Spring Boot #ComponentScan finds candidate component class but does not inject #Configuration beans but more specifically
#SpringBootApplication
#ComponentScan({"api", "rsocket", "pricing", "listeners", "dealing", "web"}) // scans packages for # components
#EnableLogging(logLevel="debug", logFile="geodeApi.log")
public class Api {
private static final Logger log = LogManager.getLogger(Api.class);
public static void main(String[] args) {
log.info("In Main");
SpringApplication app = new SpringApplication(Api.class);
app.setWebApplicationType(WebApplicationType.REACTIVE);
SpringApplication.run(Api.class, args);
log.info("Out Main");
}
}
The component scan finds various #Component annotated classes for example
#Component
#EnableClusterDefinedRegions(clientRegionShortcut=ClientRegionShortcut.PROXY)
public class ClientCache {
private static final Logger log = LogManager.getLogger(ClientCache.class);
#Resource
private Region<String, String> admin;
#Autowired
LQuote lQuote;
#Autowired
LReject lReject;
#Autowired
LDeal lDeal;
#Autowired
DealNumber dealNumber;
#Autowired
PriceService priceService;
#PreDestroy
public void onDestroy() throws Exception {
log.info("onDestroy");
String guid = UUID.randomUUID().toString().substring(0, 8).toUpperCase();
admin.put(guid, "API Shutdown");
// TODO: Cancel all open quote streams
log.traceExit();
}
#Bean
ApplicationRunner StartedUp(){
log.traceEntry("StartedUp");
return args -> {
String guid = UUID.randomUUID().toString().substring(0, 8).toUpperCase();
admin.put(guid, "API Started");
lQuote.addListener();
lReject.addListener();
lDeal.addListener();
// Get latest deal number
int currentId = dealNumber.readCurrentId();
// Set it + 1 in case the web server was reboot on the fly
priceService.setCurrentId(currentId + 1);
log.traceExit();
};
}
A lot of the problem was using Java JDK version 15.
The correct versions require Java 11.
// Geode client dependency
implementation 'org.springframework.geode:spring-geode-starter:1.2.8.RELEASE'
implementation 'org.springframework.data:spring-data-geode:2.2.8.RELEASE'
implementation 'org.springframework.boot:spring-boot-starter-tomcat'
Technically, it is not necessary to explicitly declare the SDG dependency.
The SBDG dependency (i.e. org.springframework.geode:spring-geode-starter) already includes SDG (org.springframework.data:spring-data-geode). You can follow the dependency trail starting here, then here and finally, here.
As the Version Compatibility Matrix for SBDG specifies, SBDG 1.2.13.RELEASE specifically includes, and is based on, SDG 2.2.12.RELEASE (already), which is (technically) based on Apache Geode 1.9.2.
However, if you need to use Apache Geode 1.10, then you could (recommended) simply declare dependency management to enforce the use of Apache Geode 1.10 in your Gradle build:
plugins {
id 'org.springframework.boot' version '2.2.13.RELEASE'
id 'io.spring.dependency-management' version '1.0.10.RELEASE'
id 'java'
}
dependencyManagement {
dependencies {
dependency 'org.apache.geode:geode-core:1.10.0'
dependency 'org.apache.geode:geode-cq:1.10.0'
dependency 'org.apache.geode:geode-lucene:1.10.0'
dependency 'org.apache.geode:geode-wan:1.10.0'
}
}
dependencies {
implementation 'org.springframework.geode:spring-geode-starter:1.2.13.RELEASE`
implementation 'org.springframework.boot:spring-boot-starter-tomcat'
}
...
WARNING: SDG 2.2.12.RELEASE is officially based on Apache Geode 1.9.2, and though it should work reasonably well with Apache Geode 1.10, there could expectedly be limitations in certain use cases.
This is not unlike what Spring Initializer conveniently generates for you. Of course, Spring Initializer now uses the new SBDG BOM that makes managing individual SBDG module dependencies even easier, which is not unlike how Spring Boot's dependency management manages transitive dependencies, including 3rd party libs.
Regarding the Exceptions...
It really seems to me like you are having configuration problems rather than dependency problems, actually.
Of course, it is hard to say for certain given you shared very minimal Gradle build configuration and no code snippets from your Spring Boot application configuration, only mentions and what I am able to derive from the Exception messages. So, for now, I'll proceed based on what you provided and what I know or could derive.
Looking at this part of the (first) Exception message:
Error creating bean with name 'ClusteredSpringSessions' defined in class path resource
[org/springframework/session/data/gemfire/config/annotation/web/http/GemFireHttpSessionConfiguration.class]:
Unsatisfied dependency expressed through method 'sessionRegion' parameter 0
And, specifically:
Unsatisfied dependency expressed through method 'sessionRegion' parameter 0
This message refers to the (Spring Java) configuration provided by SSDG and imported/auto-configured by SBDG.
The "Unsatisfied dependency", or "parameter 0", is the 1st method parameter in the sessionRegion(..) (Spring JavaConfig-based) #Bean definition method declared in SSDG's configuration. It is the dependency on the GemFire cache instance (e.g. ClientCache) required to create the "ClusteredSpringSessions" Region.
So now, the question becomes, how is the cache created?
Well, this is what the framework is trying to do next... resolve the cache bean dependency (instance reference), which necessary triggers the cache creation first (due to dependency order)...
Error creating bean with name 'org.springframework.data.gemfire.config.annotation.ClientCacheConfiguration':
Initialization of bean failed; nested exception is java.lang.IllegalAccessError
We see that an IllegalAccessError occurred (O.o) which already smells like a version problem to me, but...
The ClientCacheConfiguration is provided by SDG.
Finally, we arrive at the underlying cause...
class org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$703/0x0000000801025d10
tried to access protected method 'boolean org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport.hasValue(java.lang.Number)'
NOTE: ClientCacheConfiguration extends AbstractCacheConfiguration, which extends AbstractAnnotationConfigSupport, and therefore should have "access" to the protected hasValue(:Number) method.
The main Thread appears to be in one of these Lambdas where the AbstractAnnotationConfig.hasValue(:Number) method is used.
I am no entirely sure what this means...
org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$703/0x0000000801025d10
and org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport are in unnamed module of loader 'app'
Are you possibly using Spring Boot's new (Layered) Docker Image support by chance?
The 2nd Exception message (involving the cacheManager bean this time) leads to the same outcome, actually. It is no different, but simply involves another bean (i.e. cacheManager bean) with the same dependency on the cache instance:
Error creating bean with name 'cacheManager' defined in class path resource
[org/springframework/data/gemfire/cache/config/GemfireCachingConfiguration.class]
: Unsatisfied dependency expressed through method 'cacheManager' parameter 0;
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.data.gemfire.config.annotation.ClientCacheConfiguration':
Initialization of bean failed; nested exception is java.lang.IllegalAccessError:
class org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$679/0x00000008010306b8
tried to access protected method 'boolean org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport.hasValue(java.lang.Number)'
(org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$679/0x00000008010306b8
and org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport are in unnamed module of loader 'app')
And, specifically:
Initialization of bean failed; nested exception is java.lang.IllegalAccessError:
tried to access protected method 'boolean org.springframework.data.gemfire
.config.annotation.support.AbstractAnnotationConfigSupport
.hasValue(java.lang.Number)'
And:
(org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$679/0x00000008010306b8
and org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport
are in unnamed module of loader 'app')
I am not familiar with this error messages (basically, said class(es) "are in unnamed module of loader 'app'.") What?
How is this Spring Boot app being run?
Definitely providing a sample app, one or more tests, your configuration, logs, Stack Traces in addition to Exception messages, setup, runtime environment, etc, etc, will go along way in trying to understand the context of this problem.
At this point, I am really trying to point you in a direction to start untangling the problem.
Sorry, I cannot (currently) be of more help in this case.

Enable REST service for CAS Apereo version cas-overlay-template-6.0

I want to enable REST service for CAS Apereo version cas-overlay-template-6.0 (on Ubuntu 16.04)
I have done following this step:
Step 1: Add compile for REST API to build.gradle file
root#ubuntu16:~/cas-overlay-template-6.0# nano build.gradle
And add two line below under dependencies clock
compile "org.apereo.cas:cas-server-support-rest:6.0.0"
compile "org.apereo.cas:cas-server-support-rest-services:6.0.0"
Step 2: clean build
root#ubuntu16:~/cas-overlay-template-6.0# ./build.sh clean
Step 3: Build source code again
root#ubuntu16:~/cas-overlay-template-6.0# ./build.sh run
But in step 3, I got error like this.
CAS is configured to accept a static list of credentials for authentication. While this is generally useful for demo purposes, it is STRONGLY recommended that you DISABLE this authentication method (by setting 'cas.authn.accept.users' to a blank value) and switch to a mode that is more suitable for production.>
2019-12-30 01:17:55,465 WARN [org.apereo.cas.config.support.authentication.AcceptUsersAuthenticationEventExecutionPlanConfiguration] - <>
2019-12-30 01:17:55,806 INFO [org.apereo.cas.config.CasPersonDirectoryConfiguration] - <Found and added static attributes [[email]] to the list of candidate attribute repositories>
2019-12-30 01:17:59,004 WARN [org.apereo.cas.web.CasWebApplicationContext] - <Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'registeredServiceResourceRestController' defined in class path resource [org/apereo/cas/support/rest/config/RestServicesConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apereo.cas.support.rest.RegisteredServiceResource]: Factory method 'registeredServiceResourceRestController' threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: No attribute name is defined to enforce authorization when adding services via CAS REST APIs. This is likely due to misconfiguration in CAS settings where the attribute name definition is absent>
Where have I gone wrong?
Remove this:
compile "org.apereo.cas:cas-server-support-rest-services:6.0.0"
This module does this:
Invoke CAS to register applications into its own service registry. The REST call must be authenticated using basic authentication where credentials are authenticated and accepted by the existing CAS authentication strategy, and furthermore the authenticated principal must be authorized with a pre-configured role/attribute name and value that is designated in the CAS configuration via the CAS properties. The body of the request must be the service definition that shall be registered in JSON format and of course, CAS must be configured to accept the particular service type defined in the body. The accepted media type for this request is application/json.
So you can remove it, if you don't need the functionality.
If you do need it, you will need to define attribute names/values that can enforce authorization as the error message is telling you.
No attribute name is defined to enforce authorization when adding services via CAS REST APIs. This is likely due to misconfiguration in CAS settings where the attribute name definition is absent.
So, define:
# cas.rest.attributeName=
# cas.rest.attributeValue=
PS Don't add things you do not need.

Spring cloud stream: Bean 'input' defined in 'Sink' already exists in 'Processor'

Processor is the interface extending Sink and Source.
Sink creates a channel with name 'input'
In my application I have:
1. a class with #EnableBinding(Source.class) which creates 'output' channel.
2. A class with #EnableBinding(Processor.class) which has a method annotated with #Transformer(inputChannel = Processor.INPUT, outputChannel = "myOutputChannel")
3. A class with '#EnableBinding(Sink.class)' which has a method annotated with #ServiceActivator(inputChannel = "myOutputChannel")
Apparently I am not binding "input" twice, but when I run the application I get this error:
Invalid bean definition with name 'input' defined in org.springframework.cloud.stream.messaging.Sink: bean definition with this name already exists - org.springframework.cloud.stream.messaging.Processor;
any ideas why this might be? what I am doing wrong?
I had an application dropped on me which had three component applications Source, Sink, and Processor. The source class was tied to #EnableBinding(Source.class), The sink class tied to #EnableBinding(Sink.class), and the processor class was tied to #EnableBinding(Processor.class). When I updated the application to use new spring boot and cloud dependencies (spring boot 2.1.5 and cloud version is Greenwich.SR1) I started to see this error above. I updated Sink.class and Source.class to Processor.class to make sure that input and output beans are created once only and that made it work.

ModuleClassLoader singleton

I have this situation:
a JBOSS instance
application client.war
application server.war
a jboss module, properly installed, containing only the interfaces.
The server.war application implements the jboss module interfaces, and publishes these implementations with a JNDI bind. The client.war application with a lookup uses implementations server.war.
A runtime client.war can call the implementation exposed by server.war, but as soon as I try to start a transaction hibernate I get the following error:
ERROR [stderr] java.lang.IllegalStateException: JBAS016071: Singleton
not set for ModuleClassLoader for Module "client.war:main" from
Service Module Loader. This means that you are trying to access a weld
deployment with a Thread Context ClassLoader that is not associated
with the deployment.
There I bumped my head for days, but I can not understand what the problem is. Someone can help me?
Set the class loader on the child thread to be the same as the parent.
Get parent class loader:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
Set child class loader :
ClassLoader cl = Thread.currentThread().setContextClassLoader(cl);
When the child thread is done, make sure to unset the class loader to null, to avoid leaks in case of thread pools.
Although CDI will work in the child thread other things such as remote EJB invocation and JNDI lookups will not.
A much better approch wuld be to use an async EJB invocations You can just create an EJB that looks something like:
#Singleton
public class AsyncBean {
#Asynchronous
public void performTask(int a, int b) {
// the client doesn't care what happens here
}
This would mean that your async task will have the TCCL set correctly, JNDI will work etc (basically it is a full EE invocation).
You can configure the thread pool used for async invocations in standalone.xml, but it will be used for all #Asynchronous methods in the application.
Root Cause
When an application launches its own threads, the new threads use a classloader which is different than the classloader of the originating thread, therefore injection is failing.
Reference
https://access.redhat.com/solutions/257663

How do I correctly register a custom FormAction in Keycloak?

Keycloak 1.9.1-Final
I've implemented the following custom FormActionFactory.
public class RegistrationFormActionFactory implements FormActionFactory{
public static final String PROVIDER_ID = "rc-registration-profile-action";
#Override
public FormAction create(KeycloakSession session){
return new RegistrationFormAction();
}
#Override
public String getDisplayType(){
return "RC Profile Validation";
}
...
And the associated FormAction modeled after org.keycloak.authentication.forms.RegistrationProfile
public class RegistrationFormAction implements FormAction{
...
in META-INF/services of the jar I have a file: org.keycloak.authentication.FormActionFactory
containing only the following text:
com.realcomp.keycloak.RegistrationFormActionFactory
Within the Keycloak admin pages, I have made a copy of the Registration authentication flow and named it Copy of Registration. When adding an execution to my new flow I see my custom "RC Profile Validation" FormAction on the drop-down list of available providers. When selected, I get the following exception in the Keycloak server logs:
14:31:00,264 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-54) RESTEASY002005: Failed executing POST /admin/realms/master/authentication/flows/Copy of registration registration form/executions/execution: org.jboss.resteasy.spi.BadRequestException: No authentication provider found for id: rc-registration-profile-action
at org.keycloak.services.resources.admin.AuthenticationManagementResource.addExecution(AuthenticationManagementResource.java:394)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
(omitted...)
Interesting side note: If I change the PROVIDER_ID in my FormActionFactory to "registration-profile-action" everything works as expected. However, this PROVIDER_ID is used by the RegistrationProfile class and feels wrong.
I increased logging verbosity and it appears my FormAction is being loaded:
17:07:20,659 DEBUG [org.keycloak.services] (ServerService Thread Pool -- 50) Loaded SPI form-action (providers = [registration-profile-action, rc-registration-profile-action, registration-recaptcha-action, registration-password-action, registration-user-creation])
I've likely missed some configuration step. Any ideas on what I did wrong here?
This is a bug that came on version 1.9.x.
An issue ticket has already been created, you can follow it here:
https://issues.jboss.org/browse/KEYCLOAK-2842