Skip to content

Setting up SimpleSAMLPhp and passing required parameters

Jump to bottom
surfrock66 edited this page Feb 17, 2022 · 1 revision

Last updated 2022.02.16

The biggest feature-add to our implementation of this tool is the use of SimpleSAMLPhp as a SAML provider, acting as a bridge to a directory service like ActiveDirectory or OpenLDAP. If you are unfamiliar with SimpleSAMLPhp, a simple explanation is that you will have a web site as your "Identity Provider" or "IdP" which is the authoritative link back to your authentication source. While SimpleSAMLPhp can use Facebook, Twitter, OAuth, Microsoft Live and many other identity sources as the directory of choice, we implemented this to work specifically with ActiveDirectory and OpenLDAP as a standard business implementation. Once that is set up as its own site, multiple other services (referred to as "Service Providers" or "SP") can be protected by and exchange identity information with the "Identity Provider." In short, you navigate to your web service, you are redirected back to the SAML "Identity Provider" page to log in, upon successful login the PHP session is populated with specific directory information from your authentication source (AD/LDAP), and you are redirected back to the "Service Provider" with access to the directory information.

SimpleSAMLPhp is well documented, but can be difficult to set up and the terminology can be a bit confusing at first. What is helpful to understand is that both an IdP and an SP will start with the same SimpleSAMLPhp code, and certain configurations, directories, and files will be filled out or omitted depending on the role. Once both sites are set up, a metadata exchange will happen between them which establishes the trust required to securely provide authentication and metadata. The SP configuration is much more lightweight than the IdP configuration; we typically include a "simplesaml" subdirectory in the web root of an application needing to be protected by SAML. That directory is copied from a template we have already used in other applications, then the certificates, configuration, and metadata are updated and exchanged. Once a SAML SP is tested, the actual web application becomes protected with a small bit of PHP at the front of the index or header page.

We recommend review of the following:

The configuration file for this application allows defining the SP name and a URL which a user will be directed to upon logout.

While different SP's may require the IdP to provide various attributes, for our purposes 3 attributes must be made available to the session:

  • "givenname" as the user's first name
  • "surname" as the user's last name
  • "extension" as the user's extension

The attributes do not need to be named with those names in your directory; the configuration file permits an "attribute map" for any or all of the attributes; for example if the "homePhone" LDAP attribute is desired, that can be mapped to "extension."

Clone this wiki locally