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.