Enable tomcat manager to reload shibboleth

It would be useful to be able to reload shibboleth without having to stop and restart tomcat. It is actually possible, but it is necessary to enable the manager servlet, which requires some steps.

First of all, install

sudo apt-get install tomcat5.5-admin

Then configure apache to handle /manager url though mod_ajp: add the following line in the ssl virtual host (then reload apache)

ProxyPass /manager ajp://localhost:8009/manager

Change permission to manager deployment fragment so it could be executed by tomcat5 user:

sudo chmod +x /etc/tomcat5/conf/Catalina/localhost/manager

Then create a principal able to access the manager web page: edit /etc/tomcat5.5/tomcat-users.xml by adding a user like:

<user username="admin" password="secret" roles="standard,manager"/>

(role admin is necessary to access to manager)

Then you can use the commands listed at:
http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html#Introduction

For instance, to reload shibboleth:

https://idp.server.com/manager/reload?path=/idp

Server side sort with OpenLDAP2.4.18

OpenLDAP2.4.18 sports server side sorting (RFC 2891).

First of all, during configuration, sss should be enabled:

./configure --enable-hdb=yes --enable-sssvlv --enable-ppolicy --with-cyrus-sasl --with-tls=openssl

Then in slapd.conf, overlay has to be enabled:

overlay sssvlv

This line has to be added either in the global part or inside a backend directive.

Then, a ldapsearch can test the feature:

/usr/local/bin/ldapsearch -h localhost -x -E 'sss=cn' 'sn=m*' cn

if there is an attribute with a ordering rule.

If not, an error arises:

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: sn=m*
# requesting: cn 
# with server side sorting control
#

# search result
search: 2
result: 18 Inappropriate matching
text: serverSort control: No ordering rule

# numResponses: 1

You can add ordering rules to schemas: for instance to add ordering rules to sn, modify sn entry in core.schema as follows:

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
 DESC 'RFC2256: last (family) name(s) for which the entity is known by'
 ORDERING caseIgnoreOrderingMatch
 SUP name )

This time ldapsearch returns:

# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.474 false MIQAAAADCgEA
sortResult: (0) Success

# numResponses: 4602
# numEntries: 4601

Install shibboleth DiscoveryService1.1.1

Instructions are ok, but I tripped on some pitfalls.

1) when deploying service, service name has to be

discovery

, so the URL in tomcat should be /discovery and deployment fragment in /etc/tomcat5.5/Catalina/localhost should look like:

<Context docBase="/opt/shibboleth-ds/war/discovery.war"
         privileged="true"
         antiResourceLocking="false"
         antiJARLocking="false"
         unpackWAR="false" 
  swallowOutput="true" />

this should be obvious from war name, but not to me.
2) before doing install.sh I had to remove servlet-api-2.3.jar from directory /lib. Otherwise I had an error in tomcat:
INFO:
validateJarFile(/var/lib/tomcat5.5/webapps/discovery/WEB-INF/lib/servlet-api-2.3.jar)
- jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
javax/servlet/Servlet.class
3) no log starts, unless you hit the url of the discoveryService, which is https://my-server.com/discovery/WAYF
4) session initiator of shibboleth-sp should look like:

<SessionInitiator acsByIndex="false" type="Chaining"
Location="/discovery" id="discovery" relayState="cookie">
                <SessionInitiator type="SAML2" defaultACSIndex="1"
template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" defaultACSIndex="5"/>
                <SessionInitiator type="SAMLDS"
URL="https://my-server.com/discovery/WAYF"/>
            </SessionInitiator>

With the SP packeged with debian/lenny, i had to add
acsByIndex="false" in the first line.
5) with the same shibboleth-sp I had to regenerate metadata from Shibboleth.sso/Metadata, as it was missing:

<md:Extensions>
      <DiscoveryResponse
xmlns="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
Location="http://bacedifo.cesia.unimo.it/Shibboleth.sso/discovery"
index="1"/>
    </md:Extensions>

before the keys section (<md:KeyDescriptor use="signing">), inside md:SPSSODescriptor section.

Query Shibboleth2 Attribute Authority without WebSSO

First of all, please read the illuminating thread on shibboleth mailing list titled How can I only use AA of Shibboleth IdP, specially Tom Scavo's answer.

In this post I would like to show how to query the Shibboleth AA remotely from command line. This query can be well authomated in a kind of web service, which offers the informations Shibboleth gathers from different sources exactly as offered to Shibboleth SP.

The tool used is curl. It is necessary:
* craft a valid attribute request to send to shibboleth-idp
* relax security to accept queries authentication-less.

Actually authentication works as in Shibboleth-SP1.3 attribute query: requester is authenticated with x509 client certificates.

Create a valid attribute request with curl

sudo curl -v -K .curlrc

with

 $ cat .curlrc
 url =
 "https://idp.site.com:8443/idp/profile/SAML1/SOAP/AttributeQuery"
 cert = "/etc/ssl/certs/client.pem"
 key = "/etc/ssl/private/client.key"
 cacert = "/etc/ssl/certs/ca-chain.pem"
 data-binary = @soap.xml

and

 $ cat soap.xml
<?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
 <S:Body>
 <samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
 IssueInstant="2009-06-10T07:21:37Z" MajorVersion="1" MinorVersion="1"
 RequestID="_37fd92205b573e2b52d1a27e2e3b2192">
 <samlp:AttributeQuery
 Resource="https://moodle-idem.unimore.it/shibboleth">
 <saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
 <saml:NameIdentifier
Format="urn:mace:shibboleth:1.1:nameid-format:unspecified">the_username</saml:NameIdentifier>
 </saml:Subject>
 </samlp:AttributeQuery>
 </samlp:Request>
 </S:Body>
 </S:Envelope>

Please note the_username is the principalName in the IdP Attribute Resolver.

Configurations changes on the IdP

You should instruct IdP:

• Accept Attribute query without former authentication


• Map the nameid in the query with a local principal

The first is done in relying-party.xml: just comment out the lines about samlsec:Replay e samlsec:IssueInstant from SecurityPolicy shibboleth.SAML1AttributeQuerySecurityPolicy (of course IssueInstant is just not to have to forge the correct datetime, if you script it you could enforce this control).

The second is done in attribute-resolver.xml: modify line

<resolver:PrincipalConnector xsi:type="Transient" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="saml1Unspec"
        nameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

to

 <resolver:PrincipalConnector xsi:type="Direct" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="direct"
        nameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

It should be safe doing that because there are three nameId format, the 2.0 is used by Shibboleth-sp2.0 (which actually does not request attribute query, anyhow), the 1.0 is used by Shibboleth-sp1.3, so 1.1 format should be unused, unless othe saml clients do. In the latter case, I have no idea how to solve the issue.

Metadata

In metadata you should add a SP-like entry with the client certificate used by curl. Attribute filter applies rule according to this fake SP-entry.