SSO Across Two Domains That I Own

[Guest]

Hello All,

I own two domains, both running ColdFusion 9, both on the same server. Both of these domains run an Application.cfc file, and operate as independent sites. What I would like to do is allow a person from Site A to access Site B, or visa-versa. Currently, I've managed to use CFHTTP to port a persons credentials from Site A over to Site B. I've even dumped the SESSION scope when I click my link from A to B, and everything appears to be in order. So, I can see my Site A session on Site B without any issues. However, the problem that I'm running into is that after I initially get access into site B (from A), the session gets dropped and I'm forced to re-log into Site B.

I've determined that the onSessionStart method is running even though I'm passing in a CFID, JSessionID, and CFTOKEN. Is there any way to bypass or fake this so that I can simply pass over my SESSION struct from Site A to B, and have B recognize me as if I'm a logged in user?

Thanks in advance.

Keywords: Single-Sign On, ColdFusion, SSO, SSO Integration, Same Domain, 2011

[JMF3]

Use client scope instead of session, and set the client scope up to use

database tables to store the keys. That allows the application to keep

track of user sessions across servers. Alternatively, use clustering if

you're on CF Enterprise.

The simple session is essentially a contract between the server and the

browser, so it doesn't translate from one server to another. The client

scope is a contract between the application and the browser, so it can be

maintained. And clustering uses a whole different session layer to keep

track of sessions across servers.

[Owainnorth]

The problem is that both session and client scopes are maintained using Cookies stored in the browser, and there is *no way* of getting a browser to send a cookie from one domain to a different site - it'd be a security nightmare. Therefore you're probably looking at having to pass the CFID and CFTOKEN in every URL, and even then does CF even support sharing session scopes across applications?

I really don't know. But I'll be honest, you're going to struggle - you're trying to crowbar in something the internet really isn't designed to do I'm afraid.

[JMF3]

No, you don't need to use CFID / CFTOKEN in your calls at all when using

Client scope. The application smoothly picks up from one server to the

next. If you're actually changing domains, then, yes, you do have to send

the tokens across, like changing from http to https, for example. But if

you've just got 2+ web servers in a load-balance environment or something,

the Client-based session is seamless.

[Owainnorth]

But if you've just got 2+ web servers in a load-balance environment or something, the Client-based session is seamless.

Indeed, this is how we do things on our loadbalanced farm. However the OP is talking about cross-domain client scoping.

[JMF3]

erg ... yep, missed that ...

[recursivecodes]

When you pass the user from Site A to Site B you could probably serialize and store the session object to disk/memory and use a token in the URL that can be picked up in onSessionStart from the other app to then deserialize the session object and reinstantiate it.  It would be pretty trivial to do.  Maybe I'll work up an example for you - give me a bit.

[Dave Watts]

This is actually a common problem, but CF doesn't really give you any tools to solve it "out-of-the-box" so to speak. There are plenty of third-party products that do this, such as CA SiteMinder, Tivoli Access Control, etc. This problem is also often solved with tools like SAML, OpenID, and other "federated login" tools. But you can build a solution with CF.

Basically, as you've discovered, you can't really rely on cookies and sessions to make this happen. You need to be able to go to one domain and have it authenticate you, and have it redirect you to another domain which also authenticates you, and have each domain set an authentication token. Within the redirect, you'll want to include a URL parameter that tells the second domain that you're already authenticated by the first - this parameter could be an encrypted value that the second domain can decrypt, or a token that the second domain could look up against a database query, etc.

Dave Watts, CTO, Fig Leaf Software

http://www.figleaf.com/

http://training.figleaf.com/