Setting up Shibboleth IdP to mock SAML provider

[Peter Schober]

* Brandon Chinn <brandon at leapyear.io> [2019-06-06 22:36]:
> The main part I'm having trouble figuring out is how to configure a
> Shibboleth IdP, in general, to register an auth flow and SP. Mainly, I
> would like clarification on how to fill in this workflow:

You dont have to care about many of those things, that's why you use a
full-blown enterprise-ready application, not some toolkit.

> 1. User goes to
> `SHIBBOLETH_HOST/idp/profile/SAML2/Unsolicited/SSO?providerId=foo` in a
> browser

Your choice, that's a proprietary replacement for a standard SAML 2.0
authentication request.

> 2. Shibboleth serves a web form where the user fills out username and
> password

Your choice, it doesn't have to be forms-based auth, but sure.

> 3. Shibboleth IdP looks up the ____ element in ____.xml to get the SP
> referred to by providerId
> 4. Shibboleth IdP then looks up the _____ element in ____.xml to get the
> auth rules for the given SP
> 5. Shibboleth IdP looks up the _____ element in ____.xml to find the JAAS
> module to use to authenticate the user
> 6. Shibboleth IdP calls the JAAS module with the user credentials to check
> if valid

The IDP generally requires SAML 2.0 metadata for the SPs it integrates
with.  Unless you configure it to work with SPs it doesn't even have
metadata for, though I don't know how well that works with proprietary
authn requests ("IDP-initiated") instead of SAML authn requests.

Unless you need to do fancy stuff the IDP doesn't differentiate auth
methods between SPs. It certainly can, though.

And JAAS is configured once and always used in the simplest case, so
isn't dynamic or dependent on the subject or the SP.

But the IDP can be made to do many, many things, if needed.
Doesn't mean that you have to do those, if course.

> 7. If so, Shibboleth IdP returns a 302 response with the signed SAML
> document, and the user is redirected to the SP.

Not literally: SAML does not allow use of the HTTP-Redirect protocol
binding to send the Response (only for Requests) due to size constraints.
I.e., it generates a hiden HTML form and triggers the subject's user
agent to HTTP-POST the SAML response to the SP's Assertion Consumer
Service URL (known from metadata and/or an authn request). What the SP
does with that -- decode, decrypt, parse data, perform authz, redirect
the subject to the protected resource, etc. is up to the SP.

> Is this correct? Please let me know, also, if I should be asking
> another mailing list (like saml-dev) instead.

Depends. If you want to learn SAML WebSSO because you're on the
ill-advised journey of implementing a SAML SP yourself such questions
should probably be asked on saml-dev.
Questions relating to the use and configuration of the Shibboleth IDP
software are fine here, but you'll need to be prepared for some RTFM
as there's plenty of existing material, including background info:
https://wiki.shibboleth.net/confluence/display/CONCEPT/
E.g.
https://wiki.shibboleth.net/confluence/display/CONCEPT/FlowsAndConfig
https://wiki.shibboleth.net/confluence/display/CONCEPT/Metadata

-peter