Can we use Shibboleth for... ?

[Peter Schober]

Aris,

* Aristeidis Koliopoulos <akoliopoulos at cepr.org> [2020-04-02 11:33]:
> Good morning to all,

What's with the click bait in the subject? That's not how you
introduce yourself to a community of volunteers helping each other.

> For all of the things that we do, we have a DB (based on CiviCRM
> opensource CRM system). I am hoping to find a way to offer SSO to
> our members and our various website visitors through a single
> solutions. 

According to a random search result for "CiviCRM SAML"...
https://civicrm.stackexchange.com/a/26993
"CiviCRM runs within a CMS: Wordpress, Drupal [...]".
And there are SAML-integrations available for Wordpress and Drupal.

> Currently we run 6 different websites that are stand alone and we
> manually move user information to the CRM platform.
> I would like to get to a stage that all of our users login through
> one system and are able to move between our websites without having
> to authenticate again.

Commonly the former (getting user information into applications) you
do this either by "just in case" provisioning (adding accounts to all
systems, e.g. from a batch process, via event notifications, database
triggers, etc.) or "just in time", the latter meaning that a subject
will be added to each application at the time of first access/login of
the subject, with the data required for the account to be created to
be supplied e.g. by SAML attributes (or LDAP, for that matter).

The former model (jic) requires that you have stronger IDM
capabilities and that the produces either offer approppriate
interfaces (APIs, SCIM-support, etc.) or you have the resources/skills
available to do that yourself (e.g. using Ansible or whatever).

The latter (jit) means you can often get away without out-of-band
provisioning of accounts, but assumes the SSO integration can take
care of this to some degree. (The Shibboleth SP's sessionHook can also
play a role here, doing local provisioning using your own code on
access via SSO.)
This method also has its drawbacks, mostly that people need to log in
to each system in order to "exist" (having a local account created)
there, and local accounts are pretty much universally required by
applications in order to manage those accounts (assign rights and
group memberships, for example).
So relying only on SSO (and "loose coupling" via SSO) for provisioning
user accounts will often need to be accompanied by (sometimes not very
intuitive) end-user instructions with regard to how to log in to
applications A-Z first and then notify group/person X to add their
created account to the appropriate groups in those applications, etc.
(Making this a weird ob-boarding process for the subjects that also
scales badly. OTOH once you have SSO support in an app this much
provisioning support usually comes for free.)

> Unfortunately due to our nature we do not have (or can afford)
> something like Microsoft AD or Azure AD for all of our users.

Whether that's unfortunate I'm not sure about.

> I was hoping (am hoping) to be able to use Shibboleth for both (?)
> our user directory as well as the Identity Management and Service
> Management… but since this is new to me, I thought I would ask the
> question first (thank you).

Not in the way you phrase it. Shibboleth mostly passes data around so
that data must already exist and be managed in some way, and exposed
via somewhat standardised interfaces. E.g. by default Shibboleth
supports authentication via LDAP or Kerberos, both require you already
your central store of identities plus processes to activate and also
deactivate those identities as needed.

> So is it possible (in principal) to do that? To use our CRM system
> as the “directory” for our users and Shibboleth for the rest?
> All our websites are build on Drupal 7 (and now looking to move to Drupal 8).

With the Shibboleth IDP's support for JAAS and third-party JAAS
modules you can also authenticate via a JDBC-connected RDBMS, for
example.
So if one of your applications serves (or can serve) as the central
store of all identities you can use that as authentication source of
your Shibboleth IDP and probably also as data store for user
attributes (user identifiers, names, email addresses, etc.) the IDP
would send to yuor applications (as SAML SPs) during SSO.

So yes, it's possible.

You might find doing that (turning an existing application into a SAML
IDP) a bit easier using SimpleSAMLphp, mostly because there already is
a Drupal module available just for that:
https://github.com/drupalauth/simplesamlphp-module-drupalauth

Once you have a SAML IDP set up you can use any other SAML SP
implementation to protect the other applications and get SSO (and
possibly just-in-time provisioning) to those.
That might again be using SimpleSAMLphp plus the matching Drupal
module, https://www.drupal.org/project/simplesamlphp_auth but it could
also be the Shibboleth SP implementation with the matching Drupal
module being https://www.drupal.org/project/shib_auth

Finally, if you're starting out on deploying SSO across your
applications maybe consider whether SAML is still the best choice for
that. There's a strong ecosystem around SAML SSO and application
integrations and I don't know if that exists for other protocols (such
as OIDC) yet.

-peter