1

I have an annotation @SecurityDomain("cjm") on a class. Depending on the environment where I deploy the application, I need to configure different security domains. So my idea was to use filtering: @SecurityDomain("${project.name}").

However, using the examples I found on SO, nothing works. I simply cannot replace the property

It seems weird I haven't found a nice solution for this. Probably I am searching with the wrong terminology. Or maybe, weirdly enough, it is (still) not possible.

The maven template plugin is not sufficient, it doesn't contain a filter, so I have many duplicate class compilation errors.

The project is a Java EE project, running on Red Hat EAP 7 using the keycloak saml security adapter. The @SecurityDomain is mandatory to propagate the security context from the web context to the ejb context. This is necessary when using @RolesAllowed. I logged an enhancement request to the keycloak team to automatically propagate the security context, as is done in a default scenario.

onderbewustzijn
  • 935
  • 7
  • 32
  • 1
    Did you consider using Spring configuration ? Here's the documentation : [Spring Externalized Configuration documentation](https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) – Mickael Oct 19 '17 at 10:05
  • 1
    You seem to be talking about "filtering" source code which sounds as strange idea. Don't you mind to put that security domain into property file? However, there is a plugin https://stackoverflow.com/questions/4106171/filtering-source-code-in-maven – Andriy Slobodyanyk Oct 19 '17 at 10:06
  • What about using a property with @Value(${securityDomain}) private String securityDomain and inject this value in @SecurityDomain(securityDomain) – Xavier Bouclet Oct 19 '17 at 12:34
  • @MickaëlB It is a Java EE project. I will edit my content. – onderbewustzijn Oct 19 '17 at 12:53
  • @AndriySlobodyanyk I know it is strange :) I never used it before. But because of the stupid annotation I'm forced to do it this way. I allready requested an enhancement to the keycloak team... – onderbewustzijn Oct 19 '17 at 12:54

2 Answers2

0

You can use the maven plugin "templating-maven-plugin".

Declare it in your pom.xml, add call the goal "filter-sources" :

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>templating-maven-plugin</artifactId>
            <version>1.0.0</version>
            <executions>
                <execution>
                    <id>filter-src</id>
                    <goals>
                        <goal>filter-sources</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

In the src/main/java-templates/ directory, create a java template class with the expected Maven property, for example MyMavenBuildConstant.java :

public interface MyMavenBuildConstant {
     String PROJECT_NAME = "${project.name}";
}

Run a maven build (ex. mvn clean install), to create the generated java source /target/generated-sources/java-templates/MyMavenBuildConstant.java.

You can now use the java constant in your code :

@SecurityDomain(MyMavenBuildConstant.PROJECT_NAME)
-1

You could play around to setup Environment Variables during any Maven build stage depends on your profiles for example. And then consume them on runtime stage with System.environment().

In terms of modern Docker container style of delivery it supposed to be a preferable way also

AlexGera
  • 756
  • 9
  • 19
  • 1
    True, but maven doesn't allow it by default on source code. It is perfectly applicable on resource files though. The trick here it needs to happen before the compile process. – onderbewustzijn Oct 19 '17 at 13:08
  • Why before compilation? You define it as "Depending on the environment where I deploy the application, I need to configure different security domains." - which is deploy stage but not compile in my opinion. – AlexGera Oct 19 '17 at 13:18
  • I understand your point of view. However, when Maven is compiling the .java file to a .class file, the property needs already to be set. If not, Maven cannot set properties on .class files. It needs to be done on the .java file. So it can only happen before the compile process (or phase as Maven likes to call it) – onderbewustzijn Oct 19 '17 at 13:22
  • Then I would recommend on wrap up it to custom annotations or reuse enums as parameters. – AlexGera Oct 19 '17 at 14:36