This will be quick: by applying the third solution described in the previous post the SP worked with no problem. The solution was based on ISA Server, Kentor.AuthServices and ASP.NET MVC. The ability to run sites on default HTTPS port made things simple. Linux rulez!
BUt...we are not done yet! Logout waits to be implemented.
First tests were done in a LAN type environment; unfortunately life is not so simple: targeted solution should support users outside organization as well as Service Providers hosted in third party data centres. Since we do not want our IdP to be published directly on the Internet we have to use a reverse proxy which breaks our working solution. This might be particular (in terms of lack of out of the box solution-it might exist but I was unable to figure one) to ISA server but it looks (after google-ing a little bit) that a lot of people faced the same problem.
Let's suppose our proxy has the public FQDN of proxy.mycompany.com while the internal FQDN of our Shibboleth IdP is idp.mycompany.local.
As a consequence external SP will have IdP metadata configured with URLs like https://proxy.mycompany.com/ipd/profile/SAML2/Redirect/SSO. When a request comes, the SAMLRequest will have AuthnRequest tag the attribute Destination set to this address while the proxy will forward (under default configuration) in relayed request's Host header the value of idp.mycompany.local:8443.
This behaviour will lead to the failure of the request with this error message logged (sort of...) "SAML message intended destination endpoint 'https://proxy.mycompany.com/ipd/profile/SAML2/Redirect/SSO' did not match the recipient endpoint '{https://idp.mycompany.local:8443/ipd/profile/SAML2/Redirect/SSO'".
The error is generated in class org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler, method checkEndpointURI.
We have two issues that make finding a solution non trivial:
Initially Jetty was configured to use for SSL a certificate with common name of idp.mycompany.local with matches the URL configured in ISA publishing rule.
First solution to try was to change the default ISA behaviour in terms of Host header: check the option to forward the original header but another problem popped up: Jetty was refusing the connection since the Host header did not match any valid certificates in terms of common name.
Second solution tried was to generate a trusted (internally) certificate with common name of proxy.mycompany.com. Now ISA would reject it because it attempted a SSL connection on idp.mycompany.local and received a certificate on proxy.mycompany.com.
Third solution (I haven't tried because it would not solve the problem anyway due to port translation) would be:
Now we should have circumvented our first problem but it will be of no help since the checkEndpointURI (through calling compareEndpointURIs, etc) will do a string comparison which will obviously fail due to the additional substring ":8443" in the actual receiverEndpoint.
Looking at Jetty documentation we quickly find four solutions to overcome this problem:
The solution was to use Jetty rewrite handler capabilities (http://www.eclipse.org/jetty/documentation/current/rewrite-handler.html).
Unfortunately, none of the out of the box handlers provided the required functionality so I quickly wrote one.
Before going into into writing/deploying the custom handler we have to perform some prerequisites:
org.eclipse.jetty.server.Request supports updating hots and port properties (since standard HttpServletRequest does not)First create a maven project having jetty-rewrite dependency and download sources...
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-rewrite</artifactId>
<version>9.3.5.v20151012</version>
</dependency>
First item check passed since looks like we could use
Request jettyRequest=(Request) request;
jettyRequest.getMetaData().getURI().setAuthority(host, port);
Second item check was also quick: org.eclipse.jetty.util.appendSchemeHostPort shows that if specifying default ports (depending on schema) or 0 they will not be included.
Last item requires the following steps:
Add
--module=rewrite
etc/rewrite-rules.xml
in $JETTY_BASE/start.ini, where rewrite-rules.xml contains the actual rules and should be located in $JETTY_BASE/etc/rewrite-rules.xml:
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
<!-- =============================================================== -->
<!-- Configure the demos -->
<!-- =============================================================== -->
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<!-- ============================================================= -->
<!-- Add rewrite rules -->
<!-- ============================================================= -->
<Ref refid="Rewrite">
<!-- protect favicon handling -->
<Call name="addRule">
<Arg>
<New class="ro.totalsoft.jetty.hostheaderrewriter.HostHeaderRewriter">
<Set name="header">Host</Set>
<Set name="host">proxy.mycompany.com</Set>
<Set name="port">0</Set>
<Set name="terminating">true</Set>
</New>
</Arg>
</Call>
</Ref>
</Configure>
In order to be selective (if we host also other applications in the same Jetty instance) we should also add the filtering condition
<Set name="headerValue">idp.mycompany.local:8443</Set>
The actual rewrite handler definition is located in $JETTY_HOME/etc/jetty-rewrite.xml as can be seen by inspection the $JETTY_HOME/module/rewrite.mod module definition file.
Remark: looking (as a newbie) in jetty-rewrite.xml might raise a question: what is oldhandler about? The naming is misleading, it should be something like firsthandler since it refers to the first handler in the chain of Jetty handlers. After Jetty applies the rewrite handler definition this will become the first handler in chain.
Now (supposing we have written our own header rule) we have to deploy it in the classpath known by Jetty. To do this we have to add the ext module:
--module=ext
--module=ext
The ext module will enable the lib/ext/*.jar logic.
If this module is activated, then all jar files found in the lib/ext/ paths will be automatically added to the Jetty Server Classpath.
Afterwards we can copy our jar to $JETTY_BASE/lib/ext/ and restart Jetty
**Important remark **: due to a bug (omission) in the logic that activates rules inside the rewrite handler if there is no rule defined a NullPointerException will be thrown in class org.eclipse.jetty.rewrite.handler.RuleContainer, method apply:
protected String apply(String target, HttpServletRequest request, HttpServletResponse response) throws IOException
{
boolean original_set=_originalPathAttribute==null;
for (Rule rule : _rules)
{
String applied=rule.matchAndApply(target,request, response);
if (applied!=null)
{
If no rules are defined we will land here with _rules being null...
Ww are not done yet but have made significant progress having IdP side working. As we can assume, we will face same problem on SP side (we do not really want web sites exposed directly on the Internet).
So, next post about Kentor SSO. I would expect to apply the solution with external/internal DNS and using 443 default port (Windows/IIS looks more permissive in this area)
package com.mycompany.jetty.hostheaderrewriter;
import java.io.IOException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.eclipse.jetty.rewrite.handler.HeaderRule;
import org.eclipse.jetty.server.Request;
public class HostHeaderRewriter extends HeaderRule{
String host;
int port=0;
public String getHost() {
return host;
}
public void setHost(String host) {
this.host = host;
}
public int getPort() {
return port;
}
public void setPort(int port) {
this.port = port;
}
@Override
protected String apply(String target, String value, HttpServletRequest request, HttpServletResponse response) throws IOException {
Request jettyRequest=(Request) request;
jettyRequest.getMetaData().getURI().setAuthority(host, port);
return target;
}
}
First thing that popped out in my mind after basic installation/configuration worked was to check how could be the login page customized. But where to find that page?
The answer is simple: login.vm (idp-conf\src\main\resources\views\login.vm), a template based on Velocity. It was easy to find: look at the id assigned to password field (for instance), j_password and do a recursive search in sources directory.
Note: If changing main.css is necessary please notice that the UI part is packed as idp.war...
This is not enough; we want to understand how it works and where to look if we get into trouble.
To start with: a lot of Shibbolet functionality (including UI behaviour) is based on Spring Web Flow. The main configuration file (webflow-config.xml) can be found by looking into web.config.
<servlet>
<servlet-name>idp</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>${idp.home}/system/conf/mvc-beans.xml, ${idp.home}/system/conf/webflow-config.xml</param-value>
</init-param>
...
It defines application web-flows accessible through the registry (org.springframework.webflow.definition.registry.FlowDefinitionRegistryImpl, method getFlowDefinition, spring-webflow-2.4.1.RELEASE.jar).
The flow we are interested in is that with id="SAML2/Unsolicited/SSO". When we access HTTPS://<shibblolet-url>:<https-port>/idp/profile/SAML2/Unsolicited/SSO?providerId=<SP_entityID> DispatcherHandler will finally call org.springframework.webflow.mvc.servlet.FlowHandlerMapping, method getHandlerInternal, parameter HttpServletRequest request. Request properties are as follows:
Based on pathInfo the web-flow with the matching id is activated. A breakpoint set in org.springframework.webflow.executor.FlowExecutorImpl, method launchExecution, after FlowDefinition flowDefinition = definitionLocator.getFlowDefinition(flowId); allows us to examine flowDefinition and see the states defined in the work-flow that is about to be executed.
Having a look in the flow definition (path="../system/flows/saml/saml2/sso-unsolicited-flow.xml") is quite confusing for the newbies: no actually flow description (according to what you will see in tutorials) but just two regular Spring beans definition: the point is that any such bean exposing an 'execute' method will be treated as a state-action and the methods will be called in the order of bean definition.
OK, but where comes in action our login.vm? The parent="saml2.sso.abstract" attribute in flow tag definition is the key: our flow inherits its definition from that flow (identified by this id in web-config.xml). Somehow (I haven't checked all the inheritance/definitions chain) the authn/Password sub-flow is activated, sub-flow that contains a view-state referring our template in the view attribute:
<view-state id="DisplayUsernamePasswordPage" view="login">
<on-render>
<evaluate expression="environment" result="viewScope.environment" />
<evaluate expression="opensamlProfileRequestContext" result="viewScope.profileRequestContext" />
<evaluate expression="opensamlProfileRequestContext.getSubcontext(T(net.shibboleth.idp.authn.context.AuthenticationContext))" result="viewScope.authenticationContext" />
...
The transition <transition on="proceed" to="ExtractUsernamePasswordFromFormRequest"> is activated when the Login button is pressed (id='_eventId_proceed'-> proceed constant will become available to be evaluated by the transition condition based on the convention id=_eventId_... ).
Action state ExtractUsernamePasswordFromFormRequest will be executed:
<action-state id="ExtractUsernamePasswordFromFormRequest">
<evaluate expression="ExtractUsernamePasswordFromFormRequest" />
<evaluate expression="'proceed'" />
<!-- Let the validate action handle any problems later. -->
<transition to="ValidateUsernamePassword" />
</action-state>
The <evaluate expression="ExtractUsernamePasswordFromFormRequest" /> has the role to call execute method of bean with id="ExtractUsernamePasswordFromFormRequest" ( class defined in module Shibboleth IdP :: Authentication Implementation) while <evaluate expression="'proceed'"/> just makes 'proceed' the current value to be evaluated by subsequent transitions (not actually used here but pattern used in may other places).
Finally we land in ValidateUsernamePasswordAgainstLDAP.execute method.
After about two weeks of trial and error I finally succeeded to have a SSO/SAML POC based on open source components (Shibbolet/ApacheDS/KentorIT) working.
The last step was struggling with convincing Shibbolet to respond to SAML requests.
The main problem (for newbies) is the lack of any overview type information; almost all documentation (https://wiki.shibboleth.net/confluence/display/IDP30/Home) focuses on detailed specification aspects so you get lost in tens of .properties/.xml configuration files.
Of course my first concern was about being able to set breakpoints and go step by step through sources.
Go to jetty_base and edit start.ini by adding the following lines:
-Xdebug
-Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=n
Restart jetty.
Download latest source, open main pom.xml and rebuild project.
Supposing you have the metadata file for a target SP (we do not need the SP implementation for now) deploy it in shibbolet_sp/metadata (you will also find there idp_metadata.xml, the metadata related with IsP).
Edit conf/metadata-providers.xml by adding information about you SP; something like this:
<MetadataProvider id="LocalMetadata" xsi:type="FilesystemMetadataProvider" metadataFile="%{idp.home}/metadata/mySPmetadata.xml"/>Edit conf/ldap.proprierties (watch out for useStartTLS):
Remark: This is enaough for default anonSearchAuthenticator; if bindSearchAuthenticator is required be sure to:
idp.authn.LDAP.authenticator = bindSearchAuthenticatorAt this moment we can test authentication by using the IdP initiated login URL : HTTPS://<shibblolet-url>:<https-port>/idp/profile/SAML2/Unsolicited/SSO?providerId=<SP_entityID>
<SP_entityID> is the the SP EntityId as specified in metadata file.
Logout can be achieved through https://<shibblolet-url>:<https-port>/idp/profile/Logout
In order to debug the authentication proceeds have a look in net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP (method doExecute), module Shibboleth IdP :: Authentication Implementation; also look at org.ldaptive.auth.Authenticator from ladptive-1.0.0.jar (select the jar with right click->Download source, etc).
Now, even if you will get a browser error after going through the login UI process (since we dot have the actual SP implementation) you can use browser developer tools to check the SAMLResponse (use SSOCircle POST decoder). We notice that the Subject part is encrypted.
Response configuration can be done through conf/relying-party.xml; inside <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty"> change the SAML2.SSO attributes according to your needs:
<bean parent="SAML2.SSO" p:postAuthenticationFlows="attribute-release" p:encryptAssertions="false" p:encryptAttributes="false" p:encryptNameIDs="false"/>Now we can see in clear text (after decoding) the Subject info but surprise(s):
I was used with ADFS where you can easily return sAMAcountName as NameID. It turned out to be a very difficult task so at the end of the day I gave up since I (somehow) understood that the role of NameID is different of what I wanted to achieve.
Some insights:
You can have a look at (as a starting debugging point) getSAML2NameIDGenerator method from net.shibboleth.idp.saml.nameid.impl.NameIdentifierGenerationServiceImpl, module Shibboleth IdP :: SAML Profile Implementation. The main issue here is that the returned value (saml2Generator) is an implementation of org.opensaml.saml.saml2.profile.SAML2NameIDGenerator. Since in the module there is a compile dependency only to open-saml-api-3.1.1.jar you will have to add manually in pom.xml the dependency to the actual implementation.
<dependency>
<groupId>${opensaml.groupId}</groupId>
<artifactId>opensaml-saml-impl</artifactId>
<version>${opensaml.version}</version>
</dependency>
Be sure to remove the test time dependency (a compile error will prevent to successfully compile the module anyway).
The default configured strategy relies on TransientSAML2NameIDGenerator and CryptoTransientIdGenerationStrategy (generate method).
Configuration of the strategy is done in conf/saml-nameid.xml. Initially I tried switching from <ref bean="shibboleth.SAML2TransientGenerator" /> to
<!-- urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress -->
<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
p:attributeSourceIds="#{ {'cn'} }" />
Watch out of the p:format attribute value, changed from email to transient as the net.shibboleth.idp.saml.nameid.impl.AttributeSourcedSAML2NameIDGenerator (one of the subsequent calls to other classes methods) will check for attributes with this format.
Anyway, it didn't work because here we speak about SAML attributes (that will go into Assertions) not about LDAP attributes and since I didn't get in the response no Assertions...no NameID was also generated.
After further hours spent in analysing online wiki it was obvious that AttributeResolverConfiguration was next step to success.
Having a look in conf/attribute-resolver.xml and putting breakpoints in classes like from net.shibboleth.idp.attribute.resolver.ad.impl namespace like (PrincipalNameAttributeDefinition, ScopedAttributeDefinition, AbstractAttributeReleaseAction or AttributeResolverImpl) it looked that everything went Ok since I've got all 4 attributes with the expected values (by watching variables during breakpoint sessions) but no Assertions were generated.
So I had a look in conf/atribute-filter.xml and surprise, attribute generation was filtered by a fictious EntityId of https://sp.example.org. By changing the attribute value to the right value in <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="<mySPEntityID>" /> everything started to work as expected.
As a prerequisite be sure you understand the Jetty Base concept: a separate directory structure containing just configuration info. In order to implement it you have to add JETTY_BASE environment variable to /etc/default/jetty or to /etc/environment pointing to the above mentioned directory.
Just things that went wrong during my installation (or worth mentioning) are captured here.
Run initial steps as described in general instructions section https://wiki.shibboleth.net/confluence/display/IDP30/Installation#Installation-Non-WindowsInstallation.
Go now to the container specific instructions (https://wiki.shibboleth.net/confluence/display/IDP30/Jetty93) in my case.
Create the JETTY_BASE directory structure as mentioned at and apply step by step the instructions. As I noticed afterwards, there is already a jetty_base directory in the unpacked structure (which is not copied to the target directory by the setup script). Some of the artefacts can be copied from this directory (like jars) but be aware that the content of configuration files is not exactly as what the instructions require. Delete for now all the optional files.
For start.ini:
#-Didp.home=/path/to/shibboleth-idp to -Didp.home=/opt/shibboleth-idp even if the comment suggest to let it commented!!!-Djava.io.tmpdir=tmp-Dorg.eclipse.jetty.LEVEL=DEBUG (so that we have logging info for Jetty start-up)Be sure that you deploy (and change the name and the password accordingly) a valid server side certificate as configured by the lines added in ssl.ini:
So far I didn't do any other configuration (neither logging nor SOAP sections).
Before trying to stop (Jetty is automatically launched by OS if configured as depicted in post used in previous blog) and start be sure you make jetty owner on all files in /opt/shibboleth-idp and opt/jetty directories, otherwise it will not be able to read idp.war or SSL certificate, for instance. Run sudo chown -R jetty:jetty /opt/shibbolet-idp or chmod -R a+r /opt/shibbolet-idp
After (successful or not) start have a look in logging directories of jetty_base and shibbolet-idp.
You could also use java -jar opt/jetty//start.jar -DDEBUG=true -Dorg.eclipse.jetty.LEVEL=DEBUG jetty.port=8085 (from jetty_base!; don't forget to check if /etc/environment contains the proper definition for JAVA_HOME).
Other helpful commands:
service jetty status -lnetstat -tulpn ;use this command to see what processes keep open TCP ports(sometimes Jetty service does not stop/start properly and a java process remains hanged keeping opened ports for HTTP and HTTPS which prevents restarting the service)I used the following /etc/defaults/jetty file:
JETTY_HOME=/opt/jetty
JETTY_BASE=/opt/shibboleth-idp/jetty-base
NO_START=0
JETTY_HOST=0.0.0.0
JETTY_USER=jetty
/etc/init.d/jettystart.ini (apart from JETTY_HOME, JETTY_BASE and JETTY_USER, of course) or use specific Jetty configuration options from jetty_base/etc/*.ini (like jetty.ssl.host from ssl.ini)I decided to use the following supporting software infrastructure:
I used this post as a reference: http://www.ubuntugeek.com/install-jetty-9-java-servlet-engine-and-webserver-on-ubuntu-15-04-server.html
Please notice that Shibboleth 3 installation instructions recommend usage of Oracle JDK 8 as opposed to OpenJDK so install this one if your Linux distribution does not already has it installed.
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java8-installer
Be sure to set in /etc/environment JAVA_HOME=/usr/bin/java
This will be short: trying to go forward another step with gluu I noticed that embedded SAML IdP, Shibbolet, is version 2.x, announced EOL for next year, while latest stable version is 3.1.2. Since my target was only SAML IdP I decided to go directly for Shibbolet.
At the moment of writing the current version for OxTrust on GitHub is 3.0.2-SNAPSHOT but the installed version through apt-get (I used Ubuntu 14.0.4 LTS) is 2.3.4.Final
Installation is straight forward apart from first step: echo "deb http://repo.gluu.org/ubuntu/ trusty main" > /etc/apt/sources.list.d/gluu-repo.list because sudo echo..will not work; anyway, Google is our friend for one more time (as an alternative you can do the echo in another non-secured location and use sudo cp.. afterwards).
Configuration procedure, as described in on-line documentation looks simple. Unfortunately it fails to provide all the required details. Just to mention several inconsistencies:
Configuration->Cache Refresh) while really enabling the functionality is done inConfiguration->Organization (!)Inum LDAP Server (described as the internal LDAP of the Gluu Server: if it's internal why should you re-specify it?) and why you have to provide the Server IP address in the Attribute Mapping section? (maybe this configurations have to do with external LDAP usage and some clustering configurations, just guessing)Customer Backend Key and Attributes is somehow redundant (and might induce not consistent configuration) with Attribute Mapping section: what if I define some attributes in first section and use other (as source) in the later?/opt/gluu-server/opt/apache-tomcat.../conf/oxTrustCacheRefresh.properties) neither the Velocity template (oxTrust/configuration/target/classes/conf/oxTrustCacheRefresh.properties.vm) do not have any reference to it.Anyway, here are my findings.
Fortunately the source code is available (in Maven project format) so you can enable Debug and see what's going on.
Enable debugging by changing the /opt/gluu-server/opt/apache-tomcat.../conf/gluuTomcatWrapper.conf by adding the following lines in # Java Additional Parameters section
wrapper.java.additional.8=-Xdebug
wrapper.java.additional.9=-Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=n
Restart gluu-server, start Netbeans (for instance), open pom.xml for OxTrust Server, attach debugger and place some breakpoints in org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer. Method process() is called every minute trying to do a cache refresh. It might be helpful to check also org.gluu.site.ldap.LDAPConnectionProvider in OxLdap project.
You can also check the /opt/gluu-server/opt/apache-tomcat.../logs/oxtrust_cache_refresh.log for errors if something does not work as expected.
Important remark: almost all configuration is kept also in LDAP so you can browse it through any decent LDAP browser:
Have a look at ou=appliances,o=gluu and its descendants
org.gluu.site.ldap.LDAPConnectionProvider )Change Bind PasswordWhile it looks you can add several source servers there is only one Bind Password and list of fetched attributes so this is not really useful apart from a limited workaround to the restriction imposed by the single level search.
I tested it only with one server (the Gluu-server internal OpenDJ) so I have no clue what you can achieve by adding several servers/Base DN (anyway there is again only one Bind DN/Password).
Base DN specifies ou=people,o=site; initially users were created here but due to the fact I missed to provide an Attribute mapping for sn (mandatory requirement) after struggling with various configurations and resets I deleted all entries (for users). Since no new entries appeared I looked in the other areas and I found all users (now correctly imported) in ou=people,o=@!A362.9654.1097.E56D!0001!B929.EB26,o=gluu (to mention that among them we have admin which is consistent with the hint for Keep external persons (see below). So understanding is as follows :
ou=people,o=@!A362.9654.1097.E56D!0001!B929.EB26,o=gluuI used copy and checked Keep external persons (another very nice hint in the documentation :'If you do not enable 'Keep External Person', your 'admin' user including all other test users will be gone after first Cache Refresh iteration.'; very promising apart from not being provided in the Configuration on-line help but in the overview area...)
This will provide for sure headaches since there is no mention about a tough (but normal) requirement: since default target object classes for the newly created (cached) users are gluuPerson, person,organizationalPerson, inetOrgPerson, ox-A36296541097E56D0001B929EB26, top, eduPerson, some of the through inheritance of course, you have to use only the ones defined for the above mentioned classes and include in the target attributes all required ones. At the moment of writing these are just two: cn and sn. Anyway you will get a self explanatory exception message in the above mentioned log.
Remark:The list of default object classes is defined in JSON configuration, accessible through one of the configuration menu entries.
I have used Jetty as OpenIG container (version jetty-distribution-8.1.17.v20150415).
Download the Jetty distribution and unpack it in the traget directory. Follow instructions in http://www.eclipse.org/jetty/documentation/current/startup-windows-service.html
Several remarks:
set PR_JVMOPTIONS= line to set PR_JVMOPTIONS=-Duser.dir="%JETTY_BASE%";-Djetty.port=8081;-Djava.io.tmpdir="C:\jetty\temp";-Djetty.home="%JETTY_HOME%";-Djetty.base="%JETTY_BASE%";-Dopenig.base="C:\jetty\OpenIG";-Xdebug;-Xnoagent;-Djava.compiler=NONE;-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005; so that the used port will be 8081, the debug support will be enabled and the OpenIG base directory will be set upprunsrv.exe //DS/JettyService4OpenIG (JettyService4OpenIG is the chosen name for the service);REM set PR_STOPPARAMS=--stop;STOP.KEY="%STOPKEY%";STOP.PORT=%STOPPORT%;STOP.WAIT=10REM --StartParams="%PR_STARTPARAMS%" ^Rename the war to root.war and deploy it to webapps; remove test.xml from contexts (so that the test application is not deployed (with error))
Follow the instructions in https://backstage.forgerock.com/#!/docs/openam-policy-agents/3.5.0/jee-users-guide#chap-jetty in parallel with https://backstage.forgerock.com/#!/docs/openig/3.1.0/gateway-guide#chap-password-capture-replay-tutorial to deploy the agent on the same Jetty instance
Agent Filter Mode to SSO_ONLYOpenAM Login URL to contain the realm=MyRealm query parameter*webdefault.xml in etc subdirectory of Jetty installation as mentioned in J2EE agent configuration (https://backstage.forgerock.com/#!/docs/openig/3.1.0/gateway-guide#capture-relay-setup-pa) but use <url-pattern>/replay/*</url-pattern> instead of <url-pattern>/replay/</url-pattern> (see below...).Notices:
com.sun.identity.agents.config.organization.name = /MyRealm in agents bootstrap properties (OpenSSOAgentBootstrap.properties) is set up properly the generated login URL (at runtime) will not contain the targeted realm so user authentication will take place against Top Level Realm.There is not obvious at the first glance but we must define the config.js in config subdirectory of the configuread OpenIG base directory (parameter -Dopenig.base, see above) and the specific routes in config\routes.
{
"handler": {
"type": "Router",
"audit": "global",
"capture": "all"
},
"heap": [
{
"name": "LogSink",
"type": "ConsoleLogSink",
"config": {
"level": "DEBUG"
}
},
{
"name": "JwtSession",
"type": "JwtSession"
},
{
"name": "ClientHandler",
"type": "ClientHandler"
},
{
"name": "capture",
"type": "CaptureDecorator",
"config": {
"captureEntity": true,
"_captureExchange": true
}
}
]
}
{
"handler": {
"type": "Chain",
"config": {
"filters": [
{
"type": "CryptoHeaderFilter",
"config": {
"messageType": "REQUEST",
"operation": "DECRYPT",
"algorithm": "DES/ECB/NoPadding",
"key": "xxx",
"keyType": "DES",
"charSet": "utf-8",
"headers": [
"password"
]
}
},
{
"type": "AssignmentFilter",
"config": {
"onRequest": [
{
"target": "${exchange.authInfoUsername}",
"value": "${exchange.request.headers['username'][0]}"
},
{
"target": "${exchange.authInfoPassword}",
"value": "${exchange.request.headers['password'][0]}"
}
]
}
},
{
"type": "HeaderFilter",
"config": {
"messageType": "REQUEST",
"remove": [
"password",
"username"
]
}
},
{
"type": "StaticRequestFilter",
"config": {
"method": "POST",
"uri": "https://otrs-fqdn/otrs/customer.pl",
"form": {
"User": [
"${exchange.authInfoUsername}"
],
"Password": [
"${exchange.authInfoPassword}"
],
"Action":["Login"],
"RequestedURL":[""],
"Lang":["en"],
"TimeOffset":["-180"]
}
}
}
],
"handler": "ClientHandler"
}
},
"condition": "${matches(exchange.request.uri.path, '^/replay/otrs')}"
}
{
"handler": "ClientHandler",
"condition": "${matches(exchange.request.uri.path, '^/otrs')}",
"baseURI": "https://otrs-fqdn"
}
This application is JSF based so the POST at login view must have the session cookie set. The solution is to have a first step requesting GET before so that the session is created.
{
"heap": [
{
"name": "DispatchHandler",
"type": "DispatchHandler",
"config": {
"bindings": [
{
"handler": {
"type": "Chain",
"config": {
"filters": [
{
"type": "CryptoHeaderFilter",
"config": {
"messageType": "REQUEST",
"operation": "DECRYPT",
"algorithm": "DES/ECB/NoPadding",
"key": "xxx",
"keyType": "DES",
"charSet": "utf-8",
"headers": [
"password"
]
}
},
{
"type": "AssignmentFilter",
"config": {
"onRequest": [
{
"target": "${exchange.authInfoUsername}",
"value": "${exchange.request.headers['username'][0]}"
},
{
"target": "${exchange.authInfoPassword}",
"value": "${exchange.request.headers['password'][0]}"
}
]
}
},
{
"type": "HeaderFilter",
"config": {
"messageType": "REQUEST",
"remove": [
"password",
"username"
]
}
},
{
"type": "StaticRequestFilter",
"config": {
"method": "GET",
"uri": "http://legacy-app-fqdn:8081/MyApp/faces/login.xhtml"
}
},
{
"type": "SwitchFilter",
"config": {
"onResponse": [
{
"handler": "LoginRequestHandler"
}
]
}
},
{
"type": "EntityExtractFilter",
"config": {
"messageType": "response",
"target": "${exchange.viewState}",
"bindings": [
{
"key": "value",
"pattern":
"javax\\.faces\\.ViewState\"\\s.*value=\"(.*)\"\\s*autocomplete=",
"template": "$1"
}
]
}
},
{
"type": "AssignmentFilter",
"config": {
"onResponse": [
{
"target": "${exchange.sessionCookie}",
"value": "${split(exchange.response.headers['Set-Cookie'][0],';')[0]}"
}
]
}
}
],
"handler": "ClientHandler"
}
}
}
]
}
},
{
"name": "LoginRequestHandler",
"type": "Chain",
"config": {
"filters": [
{
"type": "StaticRequestFilter",
"config": {
"method": "POST",
"uri": "http://legacy-app-fqdn:8081/MyApp/faces/login.xhtml",
"form": {
"loginForm:j_username": [
"${exchange.authInfoUsername}"
],
"loginForm:j_password": [
"${exchange.authInfoPassword}"
],
"loginForm":["loginForm"],
"loginForm:j_idt17":[""],
"javax.faces.ViewState":["${exchange.viewState.value}"]
},
"headers": {
"Cookie": ["${exchange.sessionCookie}"]
}
}
},
{
"type": "HeaderFilter",
"config": {
"messageType": "RESPONSE",
"add": {
"Set-Cookie": [ "${exchange.sessionCookie}; path=/MyApp" ]
}
}
}
],
"handler": "ClientHandler"
}
}
],
"handler": "DispatchHandler",
"condition": "${matches(exchange.request.uri.path, '^/replay/MyApp')}"
}
{
"handler": "ClientHandler",
"condition": "${matches(exchange.request.uri.path, '^/MyApp')}",
"baseURI": "http://legacy-app-fqdn:8081"
}
As I decided to abandon this solution there were things unconfigured or missconfigured. Just to mention two: