This repository has been archived by the owner. It is now read-only.
Deprecated. Meteor package for SAML authentication, built for Brown University.
Switch branches/tags
Clone or download
Pull request Compare This branch is 47 commits ahead of ritstudentgovernment:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.

accounts-saml2 is no longer used by SignMeUp in production, deprecated in favor of Google login. If you would like to take on maintenance, please email


This Meteor package implements SAML2 authentication. It is a wrapper for the node passport-saml module. It provides middleware routes for processing login, callback, and metadata requests.


meteor add athyuttamre:accounts-saml2


1. Meteor Setup

To get SAML authentication working on your local machine, you need three things:

  1. Run Meteor on SSL using nourhardy:ssl or an nginx proxy.
  2. If developing for Brown University, add an entry to your computer's hosts file for to Also make sure SSL is running on port 3000; your app can run on any other port, such as 3100.
  3. Add the settings below to settings.json.

Finally, run your app so: meteor --settings settings.json --port 3100, and navigate to in an incognito window. It's important to run this in a private window so that you can debug your login session. Right now, logout isn't supported.

Couple of tips to help you debug:

  • Monitor the Network tab within Chrome Developer Tools as you go through the login flow. Make sure Preserve Logs is checked; this way logs persist even after redirects.
  • Use to read the values of SAMLRequest and SAMLResponse, the two pieces of information that'll be sent around during these redirects. You can read the values from the Network tab above.

2. Package Setup

For the package itself, supply passport-saml SAML properties in the Meteor settings.json like so:

"saml": {
  "loginUrl": "/login",
  "protocol": "https",
  "host": "",
  "path": "/login/callback",
  "entryPoint": "",
  "issuer": "",
  "serviceProviderCert": "INSERT-SELF-SIGNED-CERT-HERE",
  "decryptionPvk": "INSERT-SELF-SIGNED-KEY-HERE",
  "identifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
  "disableRequestedAuthnContext": true,
  "metadataUrl": "/metadata",
  "attributeMap": {
    "urn:oid:": "brownAdvanceId",
    "": "brownAuthenticationProfiles",
    "urn:oid:": "brownBannerID",
    "urn:oid:": "brownBruID",
    "urn:oid:": "brownNetID",
    "urn:oid:": "brownShortID",
    "urn:oid:": "brownStatus",
    "urn:oid:": "brownType",
    "urn:oid:": "brownUUID",
    "urn:oid:": "eduPersonEntitlement",
    "urn:oid:": "eduPersonScopedAffiliation",
    "urn:oid:": "isMemberOf",
    "urn:oid:": "machineID"

Specify your callbackUrl in parts as protocol, host, and path. For all other URLs, specify relative paths beginning with a /. For files, inline the values.

Unfortunately, there isn't a clean way to read files from within a Package. Options include using Node's fs, or the app reading the file and passing to the package. The Assets API isn't available i.e. packages can't read user assets. For more discussion, see this issue. For a hacky fix, see this piece of code.

There are extra (non passport-saml) options that be provided. They are:

  • serviceProviderCert: Path to the Service Provider certificate file.
  • metadataUrl: URL which metadata can be read from.

See the Usage section of passport-saml documentation for options that can be specified.


In your app, add a button or link to initiate login, for example <a href="#" class="login">Login</a>. Then, add the following click handler to your template:

"click .login": function() {
  Meteor.loginWithSaml(function() {
    console.log("Welcome " + Meteor.user().profile.givenName + "!");

To login with a redirect (instead of a popup), specify options like so:

"click .login-with-redirect": function() {
  Meteor.loginWithSaml({loginStyle: "redirect"}, function() {
    console.log("Welcome " + Meteor.user().profile.givenName + "!");


This package gets the user's SAML attributes and stores them in the User object's profile. This is by default writable by the user themselves. Add a deny rule to the Users collection to avoid this.


Peter Mikitsh for the original version and Sumner Warren for very many contributions.