Copy link to clipboard
Copied
I have a coldfusion web application. And I want to implement SSO for my ColdFusion application.
As per my understanding ,
Also , my understanding regarding process workflow is as below ,
Also , where does the step to login to my Identity Provider come in the picture ?.
Appreciate your timely help on this.
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 t
...Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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".
Note : OneLogin is my Idp.
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
Hello Curtis,
Thank you. This helps a lot.
Copy link to clipboard
Copied
Hi Curtis,
We are also trying to implement Saml with our CF 2018 application which is setup using IIS in Windows server 2019.
Our metadata file is added in IDP and is registered as a valid SP, how can we add the IDP metadata file in our server. Is there a tool I can use. Please help me.
Copy link to clipboard
Copied
Pearlmany,
What SP software are you using?
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Hi Swathi,
Unfortunately I'm not familiar with using ADFS as a service provider/relying party. I did find this article that appears to describe how to do this: https://www.componentspace.com/Forums/PrintTopic52.aspx
Hopefully that helps!
-Curtis
Copy link to clipboard
Copied
Thank you so much