Just getting started in the world of SAML...

[Dan G. Switzer, II]

Peter,

Thanks for the reply. That helps. I do have some follow up questions.

First, we actually only have a single vhost. We use wildcard DNS to
identify the clients, so there's only one application.

What I'm hoping is that I can set up some specific URL patterns and only
those patterns are processed by the SP. I basically want something like
/sso/saml/login and /sso/saml/logout.

When the "login" pattern is hit, we'd go through the SAML authentication
and once the user has been authenticated, we'll basically pass the user
over to our own authentication/session management. Since only a very small
subset of clients would use SAML, I want to minimize the overhead. Plus,
once we authenticate we really are driving all future requests through our
establish system.

I should be able to configure just the specific locations to be monitored,
correct?

Also, so the only way I can forcefully choose the IdP for the user, is to
set up specific URL patterns. There's no way for me to pass something to
the SP on a redirect to specify which IdP to use?

I was really hoping to take directing users to a DS out of the equation.
It's a usability issue. The people signing in, won't know what IdP to
choose--which is why we want to just force them to their correct IdP.

It also sounds from your response, that the Shibboleth SP doesn't have an
easy way of getting IdP metadata into the SP--other than the XML. So if I'm
going to allow users to define their IdP, we're going to need a way to
propage all changes to all the SPs in our cluster. Correct?

Thanks for all your help! It's certainly helping to clear things up.

-Dan



On Fri, Jul 11, 2014 at 10:21 AM, Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Dan G. Switzer, II <dswitzer at pengoworks.com> [2014-07-11 16:02]:
> > 1. Do all HTTP requests get processed by Shibboleth SP, or just calls to
> > the specific URI patterns?
>
> They all do, today, unless you're setting 'ShibDisable On' for some parts:
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig
>
> > 2. When using Shibboleth SP and I'll be having multiple IdPs, it appears
> > I need to use the Discovery Server.
> >
> > How do I push new IdPs into the Discovery Service? Can I do that from an
> > REST API, where my application can push information into the DS? We
> > ideally want to preconfigure some popular IdPs and then allow users to
> > specify their own.
>
> Ideally by using a DS that will configure/update itself automagically
> based on the SAML metadata available to your SP. The Shibboleth EDS is
> a good choice for that, if you can live with the UI. Discojuice.org is
> another option (but needs discojuice.org or hacking to be usable
> standalone). Or the SWITCHwayf software. The SP's Discovery Feed could
> also be used to roll your own UI on top of data provided by the Shib
> SP.
>
> > Can I use a central DS, or should I really use a separate DS for
> > each node in my cluster? If I should install the embedded DS, what's
> > the best way to propagate changes to all my servers?
>
> The EDS does not have it's own data, it pulls a json feed from the
> Shib SP's discovery feed handler. So no maintenance needed for the EDS
> (only for the SP itself).
>
> But I thought you'll follow the model of giving each customer/IDP its
> own vhost? In that model don't need a DS as the pre-communicated
> customer-specific application URL replaces discovery, essentially.
>
> Let me note that if some of your customers have registered their IDPs
> in Identity Federations (managing SAML metadata on behalf of all their
> members) having a customer-specific vhost does not scale/work too
> well.
> Simply letting all use the same application and putting up a DS to
> pick where to authenticate works much better here and saves work for
> everyone involved.
>
> > 3. What's the best way to handle changes in the IdP's cert? If I use a
> > centralized Discovery Server, is that the only place the certs need to
> > be? If not, is there a way to push new certs into the Service Provider
> > via an REST API?
>
> Key rollover has nothing to do with discovery. If you give IDPs an
> interface to register their metadata with you (which is what I
> understood from what you wrote above) that'd also be the place where
> they'd  upload new keys. How that turns into usable metadata for your
> SAML SPs is then your problem (with you owning the registry).
>
> > 4. How can I handle directing my users to the correct IdP? We need to
> > configure specific clients to go through specific IdPs that their
> > administrators configure.
>
> By either using a DS (and letting subjects pick their IDP) or
> sidesteppingn this and giving each customer/IDP it's own URL (could be
> REQUEST_URI or a vhost). The latter makes federation impossible, as
> hinted at above.
>
> > 5. Considering that each client is going to communicate w/a specific
> > IdP, would I be better off just using OpenSAML and implement what I
> > need? Everything I've read said don't try to recreate the wheel, but
> > really all I need to do is generate the initial request to the IdP and
> > then process the results. Would perhaps just using OpenSAML make the
> > most sense?
>
> I wouldn't consider writing my own SP. "All I need to do" is implement
> all the features I might need, and do so securely. Why not just
> install and use existing middleware that handles all that for your?
> That "each client is going to communicate w/a specifific IdP" is the
> normal and not a reason to implement a SAML SP by yourself.
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
Dan G. Switzer, II
dswitzer at pengoworks.com
http://blog.pengoworks.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140711/2e939a1b/attachment-0001.html