Need to integrate Shibboleth SP

[Cantor, Scott]

On 7/9/13 9:24 AM, "Amit Thukral" <amit.thukral403 at gmail.com> wrote:

>[athukral]: I have a configuration layer already implemented which is
>specific to our product so thats why i did not provide those details
>here. The "shib_check_user" function
> is part of a .so which is linked to our process "stm" which has the
>configuration layer already in it.

If you want to use the SP you have to be subordinate to it. The Apache
module isn't something that acts independently and then sends messages to
shibd to do a subset of things.

Rather, the module is subordinate to the SP as a whole and the core of the
system is the ServiceProvider class in libshibsp which runs various
actions against a request that supports the SPRequest interface. The job
of the module is to get the shibsp library started up with its
configuration and then expose the Apache internals via the SPRequest
interface when requests come into Apache.

Then it is meant to call the relevant ServiceProvider::doXXX methods at
appropriate times.

You can have all the separate configuration you want but you still must
instantiate the SP configuration object as part of your configuration
activity. The Apache module does that in various ways due to Apache
version differences, but Apache provides hooks for that to happen at the
right times, and anything else must also, or it won't fit well.

>   I went through an apache tutorial on "adding a module to apache"  and
>understood what you meant by configuration layer.
>   I understood that this configuration is specific to what directory is
>being accessed and what rules etc. should be governing the various
>operations etc.

That's only part of the picture, other settings are global and influence
how the library runtime is configured, such as overriding the config file
path.

>   I have all that configuration information which is passed on from my
>device but I don't know the order in which I should call the shibboleth
>APIs etc.
>    to make the basic startup happen.

The Apache or IIS modules illustrate how that happens.

>    Similarly, I did not know what all configuration I really needed from
>shibboleth2.xml for basic startup.
>Since, apache doesn't need some of them to come from shibboleth2.xml
>so I completely missed them on my another reference setup. Some of them
>apache picks up from httpd.conf.

That's a special feature that is best ignored in the initial stage of
getting something working. All of the configuration of how requests get
handled can be left to the RequestMap. Later, it may be possible to
enhance things by building something more advanced that can link local
commands that control content rules to the RequestMap interface. That's
what's inside the Apache module.

The SP requires that all of that information be exposed through the
RequestMap API. You cannot provide the information in any other way. Even
the Apache commands work that way.

>  1) <RequestMapper> - to map various requests to various application-ids.

Not just application-ids. Every property associated with a request.

>  2) <InProcess> for starting up the native logger and if any .so to be
>loaded dynamically.
>Is there anything else apart from above that I would need to provide in
><SPConfig> to make basic startup work ?

You can't pick and choose. You need to instantiate the entire SP runtime,
you don't process individual sections of the file.

>3) have not implemented anything similar to ApacheRequestMapper class.

That's optional (and see above, I wouldn't worry about it initially). But
you cannot make your native content configuration work with the SP unless
you bridge to it through that kind of class.

>   what functions I should be calling to process the incoming request ?

First you need to ensure that the incoming request is wrapped in something
that implements SPRequest by subclassing AbstractSPRequest and adding the
custom code needed.

Then you have to call doAuthentication, doExport, doAuthorization, and
doHandler in appropriate places, the latter being the way requests to the
/Shibboleth.sso virtual URLs are dispatched.

You can see all of those being called in the Apache module in particular
Apache hooks.

The doAuthentication/doExport methods are the core work done for each
request in the check_user hook. The doAuthorization method allows the SP's
pluggable access control layer to run in the Apache check_access hook.

>[athukral]: I am going through mod_shib.cpp and i believe whatever is
>being done regarding session/user mgmt etc. is already done in my WAF's
>configuration layer and I can handle those things there.

The SP doesn't function without doing its own session management, that's
what most of its code is for. If I could have used an existing session,
the code would look nothing like it does now.

>In above sentence by "different
>API" do you mean the API other than Apache, Adfs, IIS etc. for which the
>supported code is already there ?

I mean whatever proprietary API your web server uses to support modules.

The modules don't do anything fundamental except handle startup/shutdown,
shim a custom API into the SPRequest interface, and then invoke the
ServiceProvider doXXX methods at appropriate points in the request flow.

The IIS module is much shorter than the Apache module because the Apache
module adds two major pieces of work:

- supporting Apache commands via the RequestMap API
- authorization

But those are optional additions to the basic requirements.

-- Scott