Need to integrate Shibboleth SP

[Peter Williams]

If folks are using modern windows (VS isapi, from a decade+ ago) ONE might go look at the owin middleware, that abstracts hosts when doing various provider-based websso and related protocols. One could imagine a shib hander shim set (that would talk to their shibd component).




Sent from Samsung tablet



-------- Original message --------
From: "Cantor, Scott" <cantor.2 at osu.edu>
Date: 11/28/2013 4:05 PM (GMT-08:00)
To: Amit Thukral <amit.thukral403 at gmail.com>
Cc: dev at shibboleth.net
Subject: Re: Need to integrate Shibboleth SP


On 11/27/13, 5:46 AM, "Amit Thukral" <amit.thukral403 at gmail.com> wrote:
>
>Following is the current update from the last mail I had sent.
>1) After successful compilation for shibboleth-sp and supporting
>libraries, shibd comes up fine.

I doubt that you even need shibd in your design. That's a tool for
maintaining state outside of a multi-process web server.

>2) I have implemented an interface class ShibTargetWaf to work between
>the device's webserver (it is actually a reverse proxy called stm) which
>has an authentication and authorization module say "X" and shibd but the
>interface class is in very nascent
> stage and needs your input to make further progress.

I can only answer questions with specific answers that don't depend on my
spending time learning your requirements.

> so its like:
>stm->X->ShibTargetWaf->shibd

shibd is an implementation detail, it isn't part of the request processing
sequence of any system using the SP software. It is very unlikely that you
need it at all. You should probably set both the InProcess and
OutOfProcess flags when initializing the SPConfig layer and run the entire
system in one process linked to the "full" version of the libraries. No
shibd, no remoting, no extra work.

>1) could you pls. have a look at the file wafsp.cpp (interface class)
>attached and shibboleth2.xml and let me know what else I need to do ?

No, I can't. See above. All I can do is answer questions. I cannot read
your code and tell you how to build something I have no resources to work
on.

>2) There is no RequestMapper registration and invocation yet in interface
>class, following two lines are commented in shib_child_init in wafsp.cc
>
>do i need something similar ? if yes, please guide me how to do it ?

If you don't need the ability to assign properties to a request based on a
URL, then you don't need anything but a degenerate implementation of the
interface that returns whatever settings you want to apply. The
implementation provided is based on parsing out the request URL and
looking up settings based on pieces of the URL.

>3) I am planning to follow the g_Sites map way of finding hostname (as is
>done in isapi_shib.c) and initializing the same while constructing
>ShibTargetWaf object. Is it fine ?
> As of now, its hard coded.

Do you actually care what the hostname is? If you don't need to apply
policy based on URL, you probably don't care. If you do, then you would
need something like that mapping if you don't have an API in your system
to obtain the hostname. I should note that that's really a bug in your API
in that case. All web servers need to provide a means of obtaining the
proper hostname and other parameters. IIS is badly broken in not doing so.

> 4)  who should be doing the redirect to matching IDP,
> the existing authentication and authorization module "X" which already
>does authentications like LDAP, Kerberos, radius etc. and does
>authorization too ?
>OR
>should it be done from ShibTargetWaf  ?

The wrapper class is nothing but a shim between the ServiceProvider class
and the native server. In the SP, it's the ServiceProvider class, and the
handlers that plug into it, that generate redirects and do work. All the
wrapper does is translate the interface methods into native calls.

>5) once the authentication is done from IDP, the response would be
>ultimately be received on SP's assertion consumer service, and the module
>"X" should call a response handler on "ShibTargetWaf" for further
>processing, am i right here ?

Yes. The ACS is implemented as a Handler, which is really an abstraction
for anything that happens to need to fully process an HTTP request. It's
no different than what Apache calls a handler or IIS calls an ISAPI
Extension, just a different layer of code. An ACS is just a Handler that
happens to live at a particular URL, and when it gets invoked, it expects
to process a SAML SSO Response from an IdP, and then redirect to a
resource if it's successful.

I can't tell you exactly how to get the Handlers to run, you would have to
have a way to hook particular URLs and know to dispatch requests for them
to the ServiceProvider::doHandler method.

>6) if the response assertion has success response, how should I be doing
>session management in module "X", what will be the session key/id ?

I don't know that sessions even make sense in your system, but session
management is already done by the SP itself inside its code. It expects to
maintain cookies itself and if you can't use that design, then you have an
absolutely massive amount of redesign work to do. You wouldn't have any
ability to use the SP directly, you would have to change around a lot of
code. It would be a waste of your time IMHO.

So asking that question is a huge red flag.

>7) There could be multiple requests we might be sending it to IDP
>asynchronously, so how will I know which response is for which request ?

The SP doesn't care. It doesn't correlate requests to responses, it treats
each response in isolation, and the only state is in the RelayState it
generates and consumes, and that's mainly to track a resource URL.

>8) once the session expires on module "X", will I need to refresh the
>token (e.g. relay-state or something ) ? How is this token refreshed ?

SP sessions are internal to it, and when they expire, the SP just treats
the request as unauthenticated and does whatever it's configured to do for
that kind of request.

It does not have a concept of renewing or refreshing anything, and does
not connect a new session to an earlier one.

-- Scott


--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20131129/9c5d119a/attachment.html