Consortium FAQ

We get a lot of confused or mistaken requests to “join” the Consortium from people who are not clear on what Shibboleth is and isn’t. If you’re being asked to “join”, “connect”, or “support” Shibboleth and you get referred here, it’s an attempt to save us time and hopefully address that confusion.

What is Shibboleth?

We’re an open source software project that makes software to support SAML, OpenID Connect, and in general various kinds of standards supporting “federated web single sign-on”, the ability to log into web sites efficiently using a central component called an Identity Provider acting as a login service for many applications that may live in many different organizations.

Our software is “just” software, and has to be installed and managed by somebody to do what it does. We are not a service, and we do not host our software for other people or provide a shared environment you connect to by paying us. We do not provide accounts for end users, we do not see any transactions our software may be used to support, and we are not in the middle of any relationship you have with anybody you get service from (e.g., we don’t deal with libraries, journals, contracts, etc.).

In particular, we are not a service that provides subscriptions to any online resources such as library journals or databases. Our software is a means to manage access to those resources in place of other mechansisms such as proxy servers or IP restrictions, but we do not provide the subscriptions. That is a matter between your organization and those services. Paying us gets you access to none of them.

What does it mean to “support” Shibboleth as a Service Provider?

If you’re asked to support it for an application or service, what the person asking is really saying (imprecisely if not incorrectly) is that they want you to support federated login to your particular web service/platform, generally via SAML, though we do also support OpenID Connect. They want you to let their users log into your services using their local credentials via their local login server instead of requiring a password issued by you or by Google or whatever solution you might be using.

Our “niche” is higher education, where there are large federations of universities and service providers that work together on the federated login problem using the SAML standard. Our software is not unique to that use case, nor to SAML, but that’s where we have mindshare so that’s usually the source of inquiries.

Supporting the SAML standard (or the OpenID Connect specification), whether in higher education or some other sector does not require using our software. It does mean deploying some kind of new software in your infrastructure/platform that changes how you do something very, very critical and so is not a simple task or something to do on a whim. You will need help from IT staff, either yours or from a third party. And you will have to change things. There are ways to support this feature with more or less “invasiveness” but there are no “zero-footprint” options.

Our software has pros and cons like any other way of doing anything. It takes research and experience to know how to find the right solution for any technical problem, and chances are if you’re very new to the issue, Shibboleth won’t be a great fit. We make complex software for complex needs and we assume a lot of knowledge up front, as is common with open source.

What does it mean to “support” Shibboleth as an Identity Provider?

If you are part of an organization with users that access resources and services managed by other organizations and you want, or somebody has asked you, to support Shibboleth for that access, they are asking you to support federated login by your users (using your existing credentials) to other services. Generally this means via SAML historically, though we also support OpenID Connect now. You would then have to decide on an approach to deliver an Identity Provider technical solution to enable this to happen, either with software you install and run (like Shibboleth) or by buying a service from somebody else.

Our “niche” is higher education, where there are large federations of universities and service providers that work together on the federated login problem using the SAML standard. Our software is not unique to that use case, nor to SAML, but that’s where we have mindshare so that’s usually the source of inquiries.

Do I have to pay to use Shibboleth?

No and yes.

Our software is free under the Apache 2.0 software license and anybody can download or install it, there is no registration process, and no charge, for any sort of use.

We are, again, not a service you connect to, so you cannot pay us to run our software for you. There are companies that do offer that sort of thing (see the Commercial Support section of https://www.shibboleth.net/support/ ).

The technical support options we make available are a mix of free/open to all and restricted options for members. See https://wiki.shibboleth.net/confluence/display/consort/Technical+Support+Options for a summary. So it is possible to run it for free, and get free help from the community at times for relatively simple problems.

On the other hand, once you become a deployer of our software, and particularly if it’s for a commercial purpose, you should consider that you’re freeloading by taking what we make and not giving anything back. We only survive as a project because of the money people are willing to give us voluntarily. When that stops, we stop. Open source doesn’t survive when it’s literally unfunded. If you use the software, you should pay for that, and in return you will get some benefit back in the form of access to the developers for help, and a stronger voice in development priorities.

See Membership - Shibboleth Consortium for the details on this, but do understand that this is voluntary and not a condition of using the software, nor does it get you any kind of running instance of the software or an “account” or some sort of turnkey answer.