Wednesday, 2 September 2009

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.

No comments: