Alternatives to DS deployment

[Peter Schober]

* Eric Goodman <Eric.Goodman at ucop.edu> [2013-06-18 22:22]:
> I'm not sure I'm fully grokking the advice here. Are these the kinds
> of alternatives being suggested? Are there other common modes to
> consider? Or is something else implied here?

You could start by describing the specific use case here.

> * link to an existing WAYF/DS (such as InCommon's WAYF/Discovery Service) rather than deploying locally

If subjects from all IdPs in incommon are suitable to/eligible for the
service at hand, then yes. Otherwise that's will mostly lead to a bad
UX.

> * present a static list of idp-initiated SSO links

Why IdP-initiated? You're the SP, so SP-mediated IdP-initiated login
seems overly complex to me (never mind that we have all the endpoints
for SP-initiated in SAML metadata, not so for IDP-initiated).

> * present a static list of IdPs, then initiate actual authentication
>   requests by calling SAML libraries and redirecting the user directly
>   in your app (instead of having the SP do this)

Why not simply pass the IdP's entityID to the SP's Login handler? No
coding, can be done with static HTML.

Other alternatives:
* Deploy the Shibboleth EDS
* The SP can also do some stuff by tuning local templates, I'd need to
  dig up some examples I played with

-peter