Shibboleth Developers

["Scott Cantor" <>]

Here's the promised follow-up with some specifics on how the API works
and interacts with the AA. This is only dealing with the AA in terms of
its attribute responder role. The MyAA stuff and all the user interface
is obviously not part of this.

Basically, the AA is a web service (in the buzzword compliant sense)
that waits for SOAP requests on a particular SSL URL. This is the URL
you send out in the assertions issued by the handle service (using the
AABindingInfo class). We can modify the HS servlet to start including
that as well, probably specifying it in a servlet parameter.

When you get a request on that URL, you want to dispatch that to a
servlet that makes up the main part of the AA. The servlet should then
use the SAMLBindingFactory.getInstance() static method to get a binding
object that fits the policy and protocol that the AA requires (in this
case the SAML SOAP binding and Club Shib's policy).

String[] policies={Policies.POLICY_URI_CLUBSHIB};
SAMLSOAPBinding binding=
        
(SAMLSOAPBinding)SAMLBindingFactory.getInstance(SAML_SOAP_BINDING,
        
policies);

You cast the result into the base class for the protocol binding you
specified. The actual implementation may be in a further derived class,
but that's internal.

The binding object is not threadsafe (it keeps some internal state) so
you get a new one each request. We might make these a poolable resource
later, but with only one possible policy and protocol, there's not much
cost anyway, so it doesn't matter.

Anyway, the API does the work for you to unmarshal the request message
into the data you need, namely a SAMLAttributeQuery.

StringBuffer sharName=new StringBuffer();
SAMLAttributeQuery q=binding.receive(req,sharName);

You'll get back the query and the buffer gets filled in with the
authenticated name of the requesting SHAR (which I'll pull from the SSL
client cert using the req parameter).

If an error occurs, you'll catch it as an exception and then turn around
and send it back to the requester like so:
...
} catch (SAMLException e) {
        binding.respond(resp,null,e);
}

I automagically translate that into a SOAP fault or a SAML error
depending on what happened, and complete the response back to the SHAR
for you.

Assuming the request is valid, you pull the handle and security domain
out of the q variable along with the resource URI so you can locate the
policy, attributes., etc. All that is outside my scope.

When you're ready to respond, you have to build a SAMLAttributeAssertion
on the stack using the constructor and pass in an array of Attribute
objects. The API doesn't care if you implement those as plugins, with a
table-driven model, or just hardcode it, as long as the interface to the
information is by the contract I laid out.

When you have the assertion in hand, you pass it to the respond()
method:

        binding.respond(resp,assertion,null);

The response will be completed at the end of that call, and you're done.
Catch any exceptions as I noted earlier, and respond() will make sure a
reasonable response gets back to the SHAR.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--