We recommend you use the Shibboleth service provider because it is open source, freely available, and is most compliant with the SAML specifications; it is also the most widely used both in our environment and higher education in general. (SimpleSAMLphp is also a good choice and may make more sense for PHP based services.)
The SP supports active and so-called lazy sessions. Active sessions require an SSO session on all visits. For lazy sessions, the application decides when to initiate a session (by redirecting to a special handler URL).
Answer the following questions to determine how metadata will be managed:
- How will IdPs/customers get your metadata?
- How will you maintain your metadata?
- From what source will get trusted metadata?
- How will changes to metadata be handled?
Answer the following questions regarding attributes as part of planning your SP deployment:
- What attributes will you require?
- How will you use the required attributes?
- Will you be storing these attributes?
- How will you communicate your requirements to IdP operators?
- How will your application handle situations in which some of the required attributes aren't released by the IdP?
If your SP will have users from more than a single IdP, then your SP will need to handle IdP discovery. If your service works with many IdPs, you can use a discovery service such as the Shibboleth Embedded Discovery Service (EDS), a light-weight and easily-deployed solution.
You can use direct links to the Shibboleth SP's login handler if you're only interacting with a few IdPs; if you need even more customization than the EDS provides, or if you simply want an option to bypass user-facing IdP discovery.
The Shibboleth SP is made up of two components: a web server module that just listens for incoming requests, and a service/daemon that takes a handoff from the web server to do the actual work of processing requests.