Implementing Single Sign On in a Symfony2 Application

What is Single Sign On?

Single Sign On is a technology by which a user, being authenticated on a certification authority (hereinafter Identity Provider, IdP) , will be automatically authenticated on another service (hereinafter referred to as Service Provider, SP or Consumer [1-N]) of this company.

The Single Sign On mechanism is used by such sites as HabraHabr , Yandex , Google . The advantages of this approach to user authentication are obvious:

• User enters password only 1 time
• Or does not enter the password on IdP at all, if the input was used there through a social network or using OpenID
• Automatically authenticates to all company projects.
• User data can float between services from IdP to SP transparent for user

The minuses, of course, follow, as always, from the pros:
')

• Loss of the password from IdP entails the problem of entering all services
• Potentially increased risk of theft of a master session with IdP (can be reduced by linking the session to the provider's subnet, as well as using HTTPS , HTTP Only Cookies and SSL Only Cookies )
• Potentially increased risk of password theft from IdP
• ...

Despite this, from a business point of view, as well as user experience, the implementation of this functionality outweighs all the disadvantages, and the epic on the implementation of SSO in the company begins.

Before proceeding with the implementation of SSO in the company, it would be good to make sure that you are well aware of what it is:

• CSRF attacks
• MiTM attacks
• Path traversal attacks
• Execution After Redirect (EAR) attacks
• Timing attacks

and even better, how to apply them yourself .

This is important because incorrect implementation of SSO can lead to critical errors in all services that are connected to SSO: from compromising user data in one service, ending with hijacking an account in IdP, which leads to compromise of data in all services.

On Habré there is another great article on the basic principles of working with cookies and how to properly set cookies so as not to remain without pants: habrahabr.ru/company/mailru/blog/228997 .

So, after getting acquainted with the basic theory: what is SSO, security aspects that are associated with this task - we can begin to implement it.

How it will work

In general, authentication will take place in the following scenario:



Consider the scenario when the user goes to any page protected by authorization through the bookmarks (paragraph 1 in the diagram) .
Next, in Symfony2, the Entry point mechanism is activated and redirects us to our IdP, where we have to drop the OTP. There are several scenarios for the development of events:

1. The user is authenticated to IdP, then IdP simply docks into the OTP redirection chain ( step 3 in the diagram, green line)
2. The user is not authenticated to IdP, then he should be sent to the login / password input form (paragraph 3 on the diagram, red line)
3. The user generally sees us for the first time, but wants to register and goes to the registration form (At this point, the SP from which he came is saved on the IdP session.)

After the user, for example, has registered, he should be redirected to step 3 along the green line for OTP validation to SP, from which he came to us on IdP. When we validate OTP on SP, we make a trusted REST request to our IdP to make sure that such OTP really exists and has not expired in time. At this point, the REST service should invalidate this OTP. Put Lok, this operation must be atomic . Further requests with this OTP should return either HTTP 400 or HTTP 404 for SP.

In the case where IdP responded that such an OTP exists and is valid, SP authenticates the user by issuing a PreAuthenticatedToken to it.

The output will work as follows:



Please note that this type of output is considered from the point of view of the beginning of the process on the SP. This is important because the user will be returned to where he started the operation.

Suppose the user was on a certain page / secured_area and clicked on "Exit". At this point, a local logout occurs within SP. Then we go to IdP at a special URL / sso / logout , which will manage the exit from all services for this user. Since since the user has already arrived with SP, then IdP selects the next service that is in the company, and sends it to make an exit. That service, in turn, again upon completion, sends us to IdP and if the services are over, it performs a local exit (Section 5 in the diagram). After the user is sent back to the SP, from which he began to make an exit.

There is another scenario in which the user begins the process of exiting not from SP but from IdP. And it looks like this:

Certification Authority (IdentityProvider)

To make a certification center, you must first select an application in your company that will be responsible for this, like it was done in Yandex (Yandex.Passport) or in Google (Google Accounts).

In this application we will install the first part: SingleSignOnIdentityProviderBundle

SingleSignOnIdentityProviderBundle is responsible for:

• One-time password generation ( OTP )
• Remembers in session, from which SP the user came
• Functionality for exit from all SPs

We put through the composer:

php composer.phar require "korotovsky/sso-idp-bundle:~0.2.0" 

Next, update the dependencies and write our bundle in AppKernel:

We connect routes / sso / login and / sso / logout from the bundle:

Now configure the IdP bundle:

Rule security.yml:

Now you need to register SP in our bundle, for this we will create a class that immenment the \ Krtv \ Bundle \ SingleSignOnIdentityProviderBundle \ Manager \ ServiceProviderInterface interface and register it in the service container using the tag

Bundle Public API

This bundle registers with Dependency Injection several services that will be useful when customizing SSO processes in the final project.

• sso_identity_provider.service_manager - Manager for working with SP. By SP identifier returns instance of class \ Krtv \ Bundle \ SingleSignOnIdentityProviderBundle \ Manager \ ServiceProviderInterface
• sso_identity_provider.otp_manager - Manager for working with OTP. Disability check and receipt.
• sso_identity_provider.uri_signer - A service for signing urls if you need to redirect people to / sso / login yourself.

This completes the IdP setup, proceed to the SP setup.

The application in which you want to authenticate the user via IdP should set itself SingleSignOnServiceProviderBundle

SingleSignOnServiceProviderBundle is responsible for:

• Automatic IdP Authentication

We put through the composer:

 php composer.phar require "korotovsky/sso-sp-bundle:~0.2.0" 

Next, update the dependencies and write our bundle in AppKernel:

We connect the route / otp / validate / for OTP validation:

Now configure the IdP bundle:

In order for us to have an “honest” SSO, we need to choose the http method as a manager, and choose a service as a provider. To do this, you must implement the Krtv \ SingleSignOn \ Manager \ Http \ Provider \ ProviderInterface interface.

Rule security.yml:

Bundle Public API

This bundle registers with Dependency Injection several services that will be useful when customizing SSO processes in the final project.

• sso_service_provider.otp_manager - Manager for working with OTP. Check and receive.
• sso_service_provider.uri_signer - A service for signing urls if you need to redirect people to / sso / login yourself.

This completes the configuration of our applications.

To keep track of updates to bundles, put asterisks for them:

• github.com/korotovsky/SingleSignOnIdentityProviderBundle
• github.com/korotovsky/SingleSignOnServiceProviderBundle
• github.com/korotovsky/SingleSignOnLibrary