Skip to main content
A
Abdul L Koyappayil
Inspiring
June 3, 2020
Answered

SAML implementation in ColdFusion App

  • June 3, 2020
  • 2 replies
  • 4643 views

I have a coldfusion web application. And I want to implement SSO for my ColdFusion application.
As per my understanding ,

  1. Service Provider , in this case , is my ColdFusion application ?.
  2. Identity Provider is someone like Microsoft Azure ?. I am confused about this. Who should act as Identity Provider?. Do I need to create my own Identity Provider?. Or if there are already existing Identity Providers then should I register my ColdFusion application (say , www.xyz.com) with Identity Providers?.
  3. Should my ColdFusion application be "https" to register with Identity Provider?.
  4. Which one - small or small 2.0 - should I use?

 

Also , my understanding regarding process workflow is as below ,

 

  1. User click Login button on my ColdFusion application.
  2. Invoke a web service call to my ColdFusion app which then produces SAML request XML ?. What all data we need to capture in SAML request XML?
  3. My ColdFusion app then passes this SAML Request XML to Identity Provider?. How we can pass this XML to Identity Provider?. Using `<cfhttp>` tag in ColdFusion ?
  4. Identity Provider returns the SAML Response XML to our ColdFusion app ?. And then our ColdFusion app process this SAML Response XML and presents the user with the Landing page of our ColdFusion app?.

 

Also , where does the step to login to my Identity Provider come in the picture ?.

 

Appreciate your timely help on this.

      This topic has been closed for replies.
      Correct answer CurtangWarrior

      As Dave mentions yes the SP is your application. Then Azure AD, Shibboleth, ADFS, G Suite Identity, Okta, etc serve as your IdP.  In my companies case, the client has their own IdP (ADFS and Shibboleth tend to be the most common for us).

       

      The first thing you will have to do is set up a SP using some SAML compliant tool.  I have used both ShibbolethSP and simpleSAMLPHP.  simpleSAMLPHP is as the same suggests probably the simplest.  In our case we use an intermediary DB that is just used to store the attributes, access token, and timestamp from the SAML/SSO return.  Then simpleSAMLPHP passes an encrypted token to our CF application that references the auth DB to retrieve the user_id, email, etc from that table and perform authentication against the applications database.

       

      Our basic SAML/SSO Flow:

      CFApp (cflocation https://spserveraddress/idpname/) -> SPServer sends saml request and redirects to IdP login -> IdP return SAML response to SPServer -> SPServer processes response and saves data to authdb then passes generated token -> CFApp check token against auth db to retrieve authenticated user information -> CFApp performs login based on information.

       

      The basic flow for configuration with an IdP will vary depending on how you implement your SP and what IdP you are connecting to but essentially follows this:

      1. You obtain an xml file known as 'metadata' from the IdP that identfies their entityID (kinda like a name) and 509 certificates for encryption/validation of the message.  You must add this xml to your list of known IdP.  You can also subscribed to federations that will provide metadata to many different organization (InCommon for example)

      2. You provide your xml metadata file to the IdP so they can register you as a valid SP.

      3.  You then will work out which attributes you want returned from the IdP.  There is a standard set but not all of them publish everything.  We commonly use EPPN (user id), mail (email address), sn (lastname), givenname (firstname).  However any data can technically be transfered via these attributes like department_id or whatever.

       

      There is a lot that goes into these configurations and a lot of nuances depending on what you are trying to accomplish so I certainly cant provide a whole walkthrough here, but hopefully that will at least get you started.  As noted above I recommend exploring simpleSAMLPHP and you can set up a free IdP through someone like Okta for development purposes.

      2 replies

      CurtangWarrior
      CurtangWarriorCorrect answer
      Inspiring
      June 6, 2020

      As Dave mentions yes the SP is your application. Then Azure AD, Shibboleth, ADFS, G Suite Identity, Okta, etc serve as your IdP.  In my companies case, the client has their own IdP (ADFS and Shibboleth tend to be the most common for us).

       

      The first thing you will have to do is set up a SP using some SAML compliant tool.  I have used both ShibbolethSP and simpleSAMLPHP.  simpleSAMLPHP is as the same suggests probably the simplest.  In our case we use an intermediary DB that is just used to store the attributes, access token, and timestamp from the SAML/SSO return.  Then simpleSAMLPHP passes an encrypted token to our CF application that references the auth DB to retrieve the user_id, email, etc from that table and perform authentication against the applications database.

       

      Our basic SAML/SSO Flow:

      CFApp (cflocation https://spserveraddress/idpname/) -> SPServer sends saml request and redirects to IdP login -> IdP return SAML response to SPServer -> SPServer processes response and saves data to authdb then passes generated token -> CFApp check token against auth db to retrieve authenticated user information -> CFApp performs login based on information.

       

      The basic flow for configuration with an IdP will vary depending on how you implement your SP and what IdP you are connecting to but essentially follows this:

      1. You obtain an xml file known as 'metadata' from the IdP that identfies their entityID (kinda like a name) and 509 certificates for encryption/validation of the message.  You must add this xml to your list of known IdP.  You can also subscribed to federations that will provide metadata to many different organization (InCommon for example)

      2. You provide your xml metadata file to the IdP so they can register you as a valid SP.

      3.  You then will work out which attributes you want returned from the IdP.  There is a standard set but not all of them publish everything.  We commonly use EPPN (user id), mail (email address), sn (lastname), givenname (firstname).  However any data can technically be transfered via these attributes like department_id or whatever.

       

      There is a lot that goes into these configurations and a lot of nuances depending on what you are trying to accomplish so I certainly cant provide a whole walkthrough here, but hopefully that will at least get you started.  As noted above I recommend exploring simpleSAMLPHP and you can set up a free IdP through someone like Okta for development purposes.

      A
      Abdul L KoyappayilAuthor
      Inspiring
      June 7, 2020

      Hello ,

       

      Thank you for your response.

       

      I have few doubts in the SAML/SSO flow that you mentioned. You mentioned "SPServer processes response and saves data to authdb then passes generated token".

       

      1. May I know what you mean by the generated token?
      2. Are you trying to say to save details like EPPN (user id), mail (email address), sn (lastname), givenname (firstname) into the authDB?.
      3. From my CF app , when I send auth request to IdP using <cflocation> tag then the URL should be the one mentioned against SAML 2.0 Endpoint (HTTP) as shown in the below attached image. Am I correct?.

       

       

      Note : OneLogin is my Idp.

      CurtangWarrior
      CurtangWarrior
      Inspiring
      June 8, 2020

      Hi Abdul,

       

      1. Just meaning I use a generated UUID as a unique token for the saml request entry.  There is a token provided as a response but since we are connecting to ~50 different IdPs I didnt want there to be any chance of collision.  So this was just an easy way to pass the values between my SAML SP (shibboleth/php or simpleSAMLPHP) to my coldfusion app.  You could certainly pass all the attributes and things otherways, but simply passing the values I had concern over security since what would stop someone then from just passing in johndoeadmin@somedomain. This way the request is handled via a SAML compliant exchange and then handed over via a UUID based token.  Once processed the token is invalidated so its only good for one time entry.

      2. Yes so I have a simple authDB that has nothing but a simple Request table (UUID token, SAML token, eppn, domain, firstname, lastname, timestamp, etc) so when the SP successfully processes a SAML return it creates a UUID and inserts the uuid and attributes into the table then passes the UUID to my CF app.  My CF app then refernce that table to see who logged in (then invalidates the token after processing). 

      3. So yes you could send the request to the IDP using that SAML 2.0 endpoint.  But if you are just planning to receive the return directly in your CF app then you will have to encode and decode both messages (sent and received). Which ultimately will mean implementing your own SAML 2.0 compliant handling.  That is why I chose to use ShibbolethSP and simpleSAMLPHP.  Those 2 applications will handle all the SAML compliant stuff for me and I just take the returns.  So in my case I actually set up a seperate apache/httpd server with simpleSAMLPHP installed as my intermediary SP.  Lets call it auth.application.com.  And app.application.com is my CF app.  So in app.application.com when a user selects (or has a cookie that identifies them as) SSO I identify which IdP they are based on the cookie or email then forward them to a 'secured' address on my auth server: auth.application.com/sampleIDP/.  This path is set in the SP configuration to require login and be associated with the sampleIDP entity id.  So then simpleSAMLPHP performs the saml hand-shake and sends the user to sampleIDP login.  After logging in the sampleIDP returns the saml request to auth.application.com where a processing script parses the attributes, creates the UUID and saves to a DB before passing the UUID to a processing script on the application server (for example: app.application.com/process_sso.cfm.  This then receives the token checks the authDB for the values and performs login operations if the user is found.  We can also do other things like JIT (just in time) provisioning with this process if a client desires (though in general that can be a bit of a can of worms!!).

       

      Obviously I am somewhat over simplifying this but again not sure I am really capable of doing a complete walkthrough since your specifics will certainly vary.

       

      -Curtis

      D
      Community Expert
      Dave WattsCommunity Expert
      Community Expert
      June 4, 2020

      There are a lot of questions here! I'm only going to answer some of them. First, yes, your service provider is your application and your identity provider, often abbreviated to IdP, is your Azure AD or G Suite Identity or whatever you're using for identity management in your environment. And everything should use HTTPS here.

       

      Here's a good diagram showing how SAML authentication works. They also have diagrams for alternatives, like OpenID:

      https://developers.onelogin.com/saml

       

      Dave Watts, Eidolon LLC

      Dave Watts, Eidolon LLC
      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices