Can I configure com.wedgetail.idm.sso.AuthFilter dynamically
This is a 4 part answer:
First: The vsj.properties file doesn't necessarily have to live in the WAR file, it can also live in the filesystem. So, if you can choose a well-known filesystem path for all the relevant hosts and put an appropriate vsj.properties at that location on each host, then the WAR file can configure "idm.propertyFileURL" to point to that well-known path and good things will happen.
Second: (with the same caveat as above), if you are using VSJ 3.3 with "idm.keytab" and an appropriately constructed keytab then you don't need to specify "idm.princ" or "idm.realm" (or the new-for-VSJ-3.3 "idm.principalAtRealm"), because VSJ 3.3 can infer the values for idm.princ and idm.realm from the entries in the keytab (if all the entries in the keytab are for the same principal@realm). Given this, often the only difference between the VSJ configurations for different hosts is the keytab; all the other VSJ configuration parameters can be constant across all the hosts.
Third: You can do this programatically. The code in VSJ that uses init-param, context-param and vsj.properties values is just our default implementation (in the VSJ AuthFilter) of the com.wedgetail.idm.sso.AbstractAuthenticator.getConfigParam(String) abstract method. Other versions of VSJ (e.g. VSJ WebSphere Edition and VSJ JBoss Edition) provide alternative implementations of this method, and we fully intend that VSJ users can subclass the AuthFilter (or even the AbstractAuthenticator) and provide their own implementations, e.g. an implementation that looks up environment entries.
Fourth: if you have the ability to specify <Environment> entries in a Tomcat <Context>, confirm if you also have the ability to specify <Parameter> entries in the Tomcat <Context>. The <Parameter> entry is equivalent to a context-param, so then you wouldn't need to write any specific code.
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center