November 18, 2011 at 21:16Simultaneous cross-site authentication without a bike
Simultaneous cross-site authentication (SSO), why is it needed? Let's say we have it, let's call it the anachronistic term “portal”, with blogs, photos, fails (or files, whatever), call it fail.ru (not to be confused with the mail service of the same name 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 located on different domains.
And here 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.
About thisalready wrote a lot, and the code as well. But we will not go along the beaten track of bicycle building, but as real engineers we will take ready-made developments and use them. The method is simple, and even suitable for such a difficult situation.
Next, we will consider self-written alternatives, OpenID, OAuth, SAML, and why all this is generally not a good solution, issues of storing authentication data, as well as some security issues that you yourself shouldn’t climb without good knowledge, what is cross-site authentication, dispel some myths.
In real life, things are not so started up as in the case that we are considering, and sometimes it seems that you can get around the solution with setting a common cookie , but as soon as an external domain appears or a common database disappears for storing sessions, the solution disappears.
You can use the option described here , but in the comments there is quite a lot of negativity regarding iframe, javascript and other things.
There is a very interesting note on the network that OpenID solves a problem that it itself invented. OpenID is an unnecessary layer between 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, there they will either see the cookie, if you are already logged in, or ask for the email and password, you will confirm your identity, and then enter the target site, such as foo1@coolopenid.net. True, not much easier than confirming via an email link?
For cross-site authentication, OpenID is not very convenient with a large number of friendly sites, since the user will have to confirm his identity at the entrance to each site.
OAuth performs the dual task of authentication on a third-party site and authorization on a provider’s website, giving the user the opportunity to use the capabilities of a third-party resource to expand the capabilities of the provider’s website, for example, uploading links to photos on Twitter, adding information about the current location on 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 suppliers, while we still have a common central repository of user names.
A little criticism would not hurt, but I can only indirectly testify to the not very successful experience of my colleagues in implementing this solution in 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 very large.
The reader must have already realized that I am pushing for one thing, trying to convince him of the uniqueness of the right choice. Yes and no. I wanted to describe my throwing, my choice and my practice. There is no definite choice, although CAS is the simplest and most comprehensive solution for my needs and with my knowledge base.
CAS is a protocol specifically designed for simultaneous cross-site 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 supported by the fact that there is no need for the server to drag along frightening many Java dependencies (to the detriment of the need to drag along frightening many Ruby dependencies).
Also of the advantages, it can be noted that CAS can work including with thick clients , and does not even require the ability to set cookies from the client agent. There are enough clients for different platforms for easy integration of user authentication through CAS.
CAS doesn't do much. It does not store data about users, it does not store their roles, and does not know anything about other participants. As a user repository, you can use:
- a database
- LDAP / AD
- SPNEGO
- RADIUS
- a third-party service
- ... yes even a text file
It can be used with two-factor authentication and with usb tokens using X.509 certificates.
The latest update is 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.
Not the fact that everyone who uses this one of the implementations is shown here.
I will assume that these people are not such patrons to make software for someone else's common task. And since it’s done, it’s not a pity to give in general access.
You can say the same thing about the other solutions mentioned in the topic under discussion. Although, perhaps, I do not know something.
Looking right. About 3,210,000 results (0.21 seconds). If you put it in quotation marks, that is, look for an exact match - 7.5 thousand.
OpenID is not an alternative, as described above. The number of implementations does not mean ease of integration.
First entry.
1. A user visits a page that only registered users can access.
2. The site makes HTTP redirects to the CAS server.
3. The user enters a username and password.
4. CAS through the necessary adapter determines the correct username and password.
5. In case of successful authentication, the CAS server redirects the user to the page indicated by the site as the successful login page, attaching a service verification ticket in the request.
6. The site makes an internal cross-site HTTP request to the CAS server for ticket validation.
7. The user is authorized, you can associate his session cookie with the login received from the CAS server.
Re-login (for example, to site 2).
1. A user visits a page that only registered users can access.
2. The site makes HTTP redirects to the CAS server.
3. The CAS server sees the user's cookie and redirects the user to the page indicated by the site as a successful login page, attaching a service verification ticket in the request.
4. The site makes an internal cross-site HTTP request to the CAS server for ticket validation.
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.
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.
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
...
- 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 located on different domains.
And here 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.
About thisalready wrote a lot, and the code as well. But we will not go along the beaten track of bicycle building, but as real engineers we will take ready-made developments and use them. The method is simple, and even suitable for such a difficult situation.
Next, we will consider self-written alternatives, OpenID, OAuth, SAML, and why all this is generally not a good solution, issues of storing authentication data, as well as some security issues that you yourself shouldn’t climb without good knowledge, what is cross-site authentication, dispel some myths.
Successful solutions for less universal cases
In real life, things are not so started up as in the case that we are considering, and sometimes it seems that you can get around the solution with setting a common cookie , but as soon as an external domain appears or a common database disappears for storing sessions, the solution disappears.
You can use the option described here , but in the comments there is quite a lot of negativity regarding iframe, javascript and other things.
Openid
There is a very interesting note on the network that OpenID solves a problem that it itself invented. OpenID is an unnecessary layer between 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, there they will either see the cookie, if you are already logged in, or ask for the email and password, you will confirm your identity, and then enter the target site, such as foo1@coolopenid.net. True, not much easier than confirming via an email link?
For cross-site authentication, OpenID is not very convenient with a large number of friendly sites, since the user will have to confirm his identity at the entrance to each site.
OAuth
OAuth performs the dual task of authentication on a third-party site and authorization on a provider’s website, giving the user the opportunity to use the capabilities of a third-party resource to expand the capabilities of the provider’s website, for example, uploading links to photos on Twitter, adding information about the current location on 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 suppliers, while we still have a common central repository of user names.
SAML
A little criticism would not hurt, but I can only indirectly testify to the not very successful experience of my colleagues in implementing this solution in 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 very large.
Cas
The reader must have already realized that I am pushing for one thing, trying to convince him of the uniqueness of the right choice. Yes and no. I wanted to describe my throwing, my choice and my practice. There is no definite choice, although CAS is the simplest and most comprehensive solution for my needs and with my knowledge base.
CAS is a protocol specifically designed for simultaneous cross-site 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 supported by the fact that there is no need for the server to drag along frightening many Java dependencies (to the detriment of the need to drag along frightening many Ruby dependencies).
Also of the advantages, it can be noted that CAS can work including with thick clients , and does not even require the ability to set cookies from the client agent. There are enough clients for different platforms for easy integration of user authentication through CAS.
CAS doesn't do much. It does not store data about users, it does not store their roles, and does not know anything about other participants. As a user repository, you can use:
- a database
- LDAP / AD
- SPNEGO
- RADIUS
- a third-party service
- ... yes even a text file
It can be used with two-factor authentication and with usb tokens using X.509 certificates.
Kritka and myths
CAS is an old project, not developed. The current version of the server is 3.4.8, the latest revision of the protocol is 2005.
The latest update is 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 not one year old, he never received recognition - practically none. The fact that 120 schools, colleges and universities use AND MORE THAN NO ONE suggests that no one else can use it.
Not the fact that everyone who uses this one of the implementations is shown here.
CAS is developed by one firm for its specific task. The programmers who wrote CAS are committed to making their educational portal .
I will assume that these people are not such patrons to make software for someone else's common task. And since it’s done, it’s not a pity to give in general access.
CAS is a private development that does not have real success stories anywhere, except for a very narrow scope (universities, student control) and nowhere except for someone else's solution (uPortal).
You can say the same thing about the other solutions mentioned in the topic under discussion. Although, perhaps, I do not know something.
Amazingly small community. If we search the net for a typical error of a general property, then we will find only 100 reviews.
Looking right. About 3,210,000 results (0.21 seconds). If you put it in quotation marks, 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 HUNDRED implementations of OpenID providers are written?
OpenID is not an alternative, as described above. The number of implementations does not mean ease of integration.
Principle of operation
First entry.
1. A user visits a page that only registered users can access.
2. The site makes HTTP redirects to the CAS server.
3. The user enters a username and password.
4. CAS through the necessary adapter determines the correct username and password.
5. In case of successful authentication, the CAS server redirects the user to the page indicated by the site as the successful login page, attaching a service verification ticket in the request.
6. The site makes an internal cross-site HTTP request to the CAS server for ticket validation.
7. The user is authorized, you can associate his session cookie with the login received from the CAS server.
Re-login (for example, to site 2).
1. A user visits a page that only registered users can access.
2. The site makes HTTP redirects to the CAS server.
3. The CAS server sees the user's cookie and redirects the user to the page indicated by the site as a successful login page, attaching a service verification ticket in the request.
4. The site makes an internal cross-site HTTP request to the CAS server for ticket validation.
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
...