Shibboleth Developers

["Scott Cantor" <>]

> After reviewing the SHIB2 wiki, it looks like this type of solution
> would fall in the category of "Provision the Application's Database or
> Session" under Shibbolizing a Resource.

Haven't read it, but...

> I'd like to create an attribute resolver for the SP that would take the
> attributes and present them to applications in the native format.

I think you may be better off looking at the AttributeExtractor API, which
runs any time SAML attributes are processed. If you do a resolver, it's a
bit "off" conceptually.

An extractor could run, chained with the existing mechanism, and either suck
out the data again (storing it instead of creating the internal structures),
or just stack with the existing mechanism and take its output as input. In
other words, you could do:

Chain:
        SAML -> SP Attribute
        SAML -> Stored Attribute

Chain:
        SAML -> SP Attribute
        SP Attribute -> Stored Attribute

Or of course you could process the SAML into storage directly with just one
extractor if you didn't need the existing extractor at all (if the
application can't use the data anyway).

> I'm trying to get a handle on where to start with this but am fairly
> ignorant of the structure of the SP code.  I've looked around a bit but
> was wondering if I could get a pointer or two on what basic files are
> needed to stub out a resolver.  Is it sufficient just to concentrate
> attention in the shibsp/attribute/resolver/impl area?

If you're copying an implementation, yes. The headers that are installed are
the public APIs though. Nothing else is public. You should have API docs as
well (the -docs RPM or by running configure with doxygen available).

I still plan to create a skeleton project for extensions BTW.

-- Scott