Your job is to add this to the overall configuration only for the URLs matching /engine-rest/**, but to keep securing everything else with OAuth2.
Probably the order of the BasicAuthenticationFilter compared to the one responsible for OAuth2 might be critical. Or you might need a 2nd WebSecurityConfig using a different order?
You will have to study Spring Security a little deeper to figure that out. Let us know, how you solved it
but it I still get the following error when I try to use it:
“Cannot find mail configuration at: classpath:/mail-config.properties”
I am guessing I haven’t told the build to save the file in the right location?
UPDATE: I set the MAIL_CONFIG environment and put the file outside of the JAR. That seemed to fix the problem. Not sure if this is the correct way or not.
Basically it is like Gunnar said, create another WebSecurityConfig, and a filter that gets groups and username from the token.
I added some more configuration parameters, have a look at application yaml.
@VonDerBeck - how do we get SSO working for a shared process engine ? Issue #4 only describes how to add the IdentityProvider to jboss/tomcat, right ? So we’ll have to use the tomcat-keycloak adapter and do it like that : https://github.com/camunda/camunda-sso-jboss/tree/keycloak, just with your KeycloakAuthenticationProvider ?
thanks for your work I think it’s all about different flavours of the SSO example and different technology bases. For the SSO example, I concentrated on Spring Boot. It is the most suitable concept in the cloud environment. But that should not prevent using the plugin in other environments as well. We have done SSO before using Keycloak with LDAP as well, dont’ we?
You’re definitely on the right track. SSO is a concept above (additionally to) the usage of the Identity Provider Plugin. When using a shared process engine, you’ll have to use the SSO concepts for the respective technology base. Adapt to the concepts on how to do SSO on JBoss/Tomcat with Keycloak and add it to using the IdentityProvider. The Identity Provider then needs the correct User ID and groups extracted - corresponding with its configuration. Which has to be done in the KeycloakAuthenticationProvider. That part is the specific part which has to be adapted.
@cbuchberger worked like a charm. Thank you. You said you were going to provide a solution for containerized environments with that plugin. I am using openshift and would love to try it.
Currently, I had to take the great work of @VonDerBeck and add:
Email Connector
HTTP Connector
Now your additions
Groovy support
Update the DockerFile to accommodate no root permissions
I still have a lot of work to clear out some of the warnings in the build but it works.
Thank you both for all your help. This is such a great product.
Newby question: Can anyone let me know the easiest way to update the database when in springboot? I don’t know how to go into the JAR to run the database upgrade scripts.
Below are the DB scripts for upgrading camunda versions from 7.11 to 7.12 (postgres)
insert into ACT_GE_SCHEMA_LOG values (‘1’, CURRENT_TIMESTAMP, ‘7.11.3’);
create index ACT_IDX_HI_JOB_LOG_JOB_CONF on ACT_HI_JOB_LOG(JOB_DEF_CONFIGURATION_);
insert into ACT_GE_SCHEMA_LOG values (‘100’, CURRENT_TIMESTAMP, ‘7.12.0’);
ALTER TABLE ACT_HI_OP_LOG ADD ANNOTATION_ varchar(4000);
ALTER TABLE ACT_RU_JOB ADD REPEAT_OFFSET_ bigint default 0;
ALTER TABLE ACT_HI_INCIDENT ADD HISTORY_CONFIGURATION_ varchar(255);
create index ACT_IDX_HI_DETAIL_VAR_INST_ID on ACT_HI_DETAIL(VAR_INST_ID_);
That’s it, just redeploy the springboot application. Camunda version upgrade is done. For zero downtime i would recommend you to read this rolling-update.
For more detailed information, you can refer below docs.
The above Db scripts can be found here in camunda nexus.
I have incorporated the plugin in my tomact and added appropriate configurations. When I hit the login URL in browser (http://localhost:8080/camunda/login), the keycloak’s login page appears. Upon login with valid credentials I get redirected back to tasklist page but it says 404
In tomcat logs i see following error, which is from your custom java file.
Principal is null - auth not possible
Could you please let me know if any missing configuration results into this?
Hi @cbuchberger
Thank you for your reply. The issue was with my configuration in web.xml under respective webapps. The filters were not correctly placed in the web.xml file which resulted in the above mentioned error.