Simultaneous cross-site authentication without a bike

Simultaneous cross-site authentication (SSO), what is it for? Suppose we have, let's call it an anachronistic term “portal”, with blogs, photos, feils (or files, to whom how), call it fail.ru (not to be confused with the e-mail service with the letter M), and all this is complicated by the following factors :
- the functionality is completely different;
- the code is written by different people, using different technologies;
- all this works on different servers in different data centers and with different databases;
- servers are on different domains.

And at such Koshchei we will need to break an egg and give the user the opportunity to log in only once, and then go to all friendly resources without confirming their identity again.

This has already been written a lot, and the code as well. But we will not go on the beaten track of the bicycle industry, but as real engineers we will take ready-made developments and use them. The method is simple, and is suitable even for such a difficult situation.
')
Next, we will look at self-written alternatives, OpenID, OAuth, SAML, and why all this is not a generally good solution, storage of authentication data, and some security issues that you shouldn’t use without good knowledge, what is cross-site authentication in general, dispel some myths.

Successful solutions for less universal cases

In real life, everything is not so triggered, as in the case that we are considering, and sometimes it seems that you can get away with making a common cookie , but as soon as the external domain appears, or the common database for storing sessions disappears, the solution disappears.

You can use the option described here , but in the comments there is quite a lot of negative about iframe, javascript, and other things.

Openid

In the network there is a very interesting note about the fact that OpenID solves the problem, which he himself invented. OpenID is not a necessary layer between the mail and the site on which you want to authenticate. For example, you have an account on coolopenid.net, which is tied to your mail. When you enter the target site, you will be sent to coolopenid.net, they will either look at the cookie, if you are already logged in, or ask for an email and password, confirm your identity, and then enter the target site, such as, for example, foo1@coolopenid.net. True, not much easier than confirming via a link to an email?

For cross-site authentication, OpenID is not very convenient with a large number of friendly sites, since the user will have to verify his identity when entering each site.

Oauth

OAuth performs a dual task, authentication on a third-party site and authorization on the provider site, giving the user the opportunity to use the capabilities of a third-party resource to expand the capabilities of the provider site, for example, upload links to photos on Twitter, add information about your current location to Facebook. A good explanation of the difference is here . This is a wonderful and useful thing, but it is designed to combine the sites of different providers, while we still have a common central repository of user names.

Saml

A bit of criticism would not hurt, but I can only indirectly indicate the not very successful experience of my colleagues in implementing this solution into the infrastructure of a huge company with a huge number of internal and external projects. In addition, the number of libraries implementing this protocol for various programming languages ​​is not large at all.

CAS

The reader probably already realized that I am leaning towards one thing, trying to convince him of the unambiguity of the right choice. Yes and no. I wanted to describe my throwing, my choice and my practice. There is no definite choice, although for my needs and with my background of knowledge, CAS is the simplest and most comprehensive solution.

CAS is a protocol specifically designed for simultaneous intersite authentication. The protocol has at least two implementations , at least one of which is actively developing. The choice in favor of the second can be bolstered by the fact that there is no need for the server to drag after itself frightening many Java dependencies (to the detriment of having to drag at itself frightening many Ruby dependencies).

Also from the pros, it can be noted that CAS can work even with fat clients , and does not even require the ability to install cookies with a client agent. There are a sufficient number of clients for different platforms for easy integration of user authentication through CAS.

CAS does not do much. He does not store data about users, he does not store their roles, and does not know anything about other participants. As a user repository you can use:
- database
- LDAP / AD
- SPNEGO
- RADIUS
- third-party service
- ... yes even a text file

It can be used with both two-factor authentication and usb-tokens using X.509 certificates.

Crete and Myths

CAS is an old project, it does not develop. The current server version is 3.4.8, the latest revision of the protocol is 2005.

Last updated - November 9th of this year .
Apparently, the protocol fully implements the functionality necessary for the needs of SSO, and further development is not required, as, for example, the HTTP protocol has not been updated since June 1999.

CAS is an unpopular project . Despite the fact that he is more than one year old, he never received recognition - almost none. The fact that they use 120 schools, colleges and universities AND NO MORE does anyone say that no one else can use it.

It’s not a fact that all who use this one of the implementations are shown here.

CAS is developed by one firm for its specific task. Programmers who wrote CAS are committed to making their own educational portal .

I suppose that these people are not such patrons of the arts to make software for someone else’s common task. And once done, it’s not a pity to give in to the general access.

CAS is a private development that has no real success stories anywhere except in a very narrow field of application (universities, student control) and nowhere except for someone else’s solution (uPortal).

The same can be said about the other solutions mentioned in the topic under discussion. Although, perhaps, I do not know something.

Amazingly small community. If we look at the network for a typical common property error, we will find only 100 reviews.

Looking for the right. About 3,210,000 results (0.21 seconds). If you put in quotes, that is, look for an exact match - 7.5 thousand.

A surprisingly small number of implementations. Actually, there are ONLY TWO CAS server implementations. And how many COTS implementations of OpenID providers are written?

OpenID is not an alternative, as described above. The number of implementations does not speak about the simplicity of integration.

Principle of operation

First entry.
1. A user visits a page that only authorized users have access to.
2. Website makes HTTP redirect to CAS server.
3. The user enters the username and password.
4. CAS through the correct adapter determines the correct login and password.
5. In case of successful authentication, the CAS server redirects the user to the page indicated by the site as a successful login page, attaching a service check ticket in the request.
6. The site makes an internal cross-site HTTP request to the CAS server to verify the ticket.
7. The user is authorized, you can associate his session cookie with the login received from the CAS server.

Re-entry (for example, on site 2).
1. A user visits a page that only authorized users have access to.
2. Website makes HTTP redirect to CAS server.
3. The CAS server sees the user's cookies and redirects the user to the page indicated by the site as a successful login page, attaching a service check ticket to the request.
4. The site makes an internal cross-site HTTP request to the CAS server to verify the ticket.
5. The user is authorized, you can associate his session cookie with the login received from the CAS server.

This method closes a sufficient number of security holes.

Installation

1. Ruby version manager
bash <<(curl -s raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
echo '[[-s "$ HOME / .rvm / scripts / rvm"]] &&. "$ HOME / .rvm / scripts / rvm" # Load RVM function '>> ~ / .bash_profile

2. Ruby
rvm install 1.9.2
rvm use --default 1.9.2
gem install bundler

3. rubycas-server
git clone git@github.com: rubycas / rubycas- server.git
cd rubycas-server
bundle install

4. Install thin (web server) and start
gem install thin
thin start
This is the easiest, but not the best option. It is worth considering running under unicorn and nginx.

Client use

For example Ruby / Rack / Sinatra applications:

Gemfile:
...
gem 'oa-enterprise',: require => 'omniauth / enterprise'
...

Application:
...
set: login_page, "/ auth / cas"

use OmniAuth :: Strategies :: CAS,: cas_server => 'https://ruby-cas.mydomain.com'

get '/ auth / cas / callback' do
auth = request.env ["omniauth.auth"]
account = Account.first (: email => auth ["uid"]) || Account.first (: email => auth ["uid"],: role =>: external)
set_current_account (account)
redirect '/'
end
...