1. Home >
2. SAML >
3. Code Your Ruby App to Provide SSO via OneLogin

Code Your Ruby App to Provide SSO via OneLogin

Get the toolkit: 

Using the Toolkit

The lib folder contains the files you’ll copy into your Rails application. But first, let’s take a look at the sample application located here. It’s a ready-to-run SAML relying party (or service provider). The saml_controller.rb file contains all of the logic needed to authenticate using SAML:

require 'onelogin/saml'

class SamlController < ApplicationController
  skip_before_filter :verify_authenticity_token, :only => [:consume]  

  def index
    # insert identity provider discovery logic here
    settings = Account.get_saml_settings
    request = Onelogin::RubySaml::Authrequest.new
    redirect_to(request.create(settings))
  end

  def consume
    response = Onelogin::RubySaml::Response.new(params[:SAMLResponse])

    # insert identity provider discovery logic here
    response.settings = Account.get_saml_settings

    logger.info "NAMEID: #{response.name_id}"

    if response.is_valid?
      session[:userid] = response.name_id
      redirect_to :action => :complete
    else
      redirect_to :action => :fail
    end
  end
end

The index action initiates the SAML exchange.

To know where to redirect the user with the authentication request, we need to establish the user’s identity provider. This depends on your application. If accounts have a dedicated subdomain name (e.g. mycompany.accountingapp.com) or if SAML authentication for accounts is limited to certain IP ranges, you need to look up account information based on whatever information you already have about the user.

The consume action receives the SAML assertion. Again, you need to know the identity provider the user belongs to, but now you have a clue: use response.nameid to retrieve the username or email address in the SAML assertion. Then use the information to retrieve the identity provider information. You can then verify that the SAML assertion is actually from the identity provider configured on the account.

What Needs to be Configured

In the example above, SAML settings are retrieved using the get_saml_settings method on the account object. This example is generic and get_saml_settings doesn’t take any parameters. You’ll need to add your own information here (subdomain and ip_address, for example) when fetching the account, and hence SAML settings.

The following information needs to be available on the account:

• assertion_consumer_service_url

  The URL at which the SAML assertion should be received. In this example, http://localhost:3000/saml/consume would be correct.

• issuer

  The name of your application. Some identity providers might need this to establish the identity of the service provider requesting the login.

• idp_sso_target_url

  The URL to which the authentication request should be sent. This would be on the identity provider.

• idp_cert_fingerprint

  The certificate fingerprint, e.g. “90:cc:16:f0:8D:a6:D1:c6:BB:27:2D:ba:93:80:1A:1f:16:8e:4E:08”. This is provided from the identity provider when setting up the relationship.

• name_identifier_format

  Describes the format of the username required by this application. If you need the email address, use “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”. See section 8.3 of Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 for other options. Note that the identity provider might not support all options.

---