Symfony2 two-factor authentication with a certificate
It's about Symfony2-CertAuthBundle - a bundle for the popular framework Symfony2, which makes it easy to implement two-factor authentication based on x509 client certificates.
Sometimes standard authentication in the form of a login is not enough to securely protect a project.
Someone can spy, search, retrieve a login password in any other way, well, or just hack the site and get access to all accounts.
')
For those who believe that his project needs a more reliable protection method, welcome under cat.
The installation is described in detail on the githab, below I want to talk about how it works and what are the main features of the bundle.
The Security component in a symphony in the beginning seems very complicated and confusing. But in fact, everything is very simple and logical.
Security consists of four basic elements: FirewallListeners, AuthenticationProviders, UserProviders, and AuthenticationManager.
FirewallListeners are implemented by the Firewall class. They chain the request at kernel.request. Their main task is to create an unauthenticated token that will be authenticated by the subsequent AuthenticatedProvider. They are also responsible for the serialization and deserialization of the token in a session ( ContextListener ), for the redirect of the user to https ( ChannelListener ), for the ACL ( AccessListener ).
For each firewall, symphony creates its own set of listener instances. This is done in SecurityExtension.
In the power of the listener, any manipulations with the session and the token are user logins, adding dynamic roles, changing the token, etc. etc.
Through the AuthenticationManager , the listeners interact with AuthenticationProviders . The main task of providers is to load the user via UserProvider and return an authenticated token - a token with at least one role.
The AuthenticationManager implements a loose relationship between the listeners and providers through the supports () method, which allows you to write universal listeners and providers.
All these components are glued together in SecurityExtension.
Bundle adds another authentication step in the form of generating and downloading a user certificate.
The user is prompted to enter a secret word. It is necessary to encrypt the certificate before transferring it to the client and storing it on the server.
Also, the secret word is used when restoring the certificate, if the user lost it, came for another laptop or simply reinstalled the system. It is possible to disable this functionality and add your own logic for manual certificate recovery (last call, sms, last operation on the site, etc.)
After downloading and installing the certificate in the browser, the user gets full access. Bundle creates CertifiedUserToken , which is inherited from the standard UserNamePasswordToken, and also adds the ROLE_CERT_AUTHENTICATED_FULLY dynamic role, which is used in the above-mentioned AccessListener for access checking.
The main verification of the client certificate lies on the backend server (nginx, apache), which pass the result of the verification and the certificate to symfony. Variable names are configured in the config. file. Bundle only verifies the result of this check. Verification is performed using Symfony Expression Language and, by default, looks like:
In the context of the expression: cert (array in format openssl_x509_parse), the request object and the current token.
Since the server automatically validates the validFrom and validTo of the certificate, inactive accounts do not become a potential security gap over time.
The storage system ( zim_cert_auth.certificate_storage service) uses three main components: Formatter, Filters, Persister.
Formatter is responsible for converting an x509 resource to a storage format. Currently only PKCS12 formatter is implemented.
Filter allows you to apply any transformation before saving or retrieving.
Persister is responsible for the physical storage of certificates. Currently localfs and orm persists are implemented. Their purpose is clear from the title. There are plans to add a remotessh persister that will allow storing certificates on any other host using scp.
You can implement your services of formatters, persists, filters and define them in config.yml
Bundle adds several cli commands to enable certificate management. At the moment there are two commands:
zim: cert: dump and zim: cert: remove.
Since the bundle is quite young, it may lack the functionality that is needed in real projects, so any suggestions on functionality, general work of the bundle, write in comments or on githabe, we will implement all the necessary features.
Thanks to all.
Sometimes standard authentication in the form of a login is not enough to securely protect a project.
Someone can spy, search, retrieve a login password in any other way, well, or just hack the site and get access to all accounts.
')
For those who believe that his project needs a more reliable protection method, welcome under cat.
The installation is described in detail on the githab, below I want to talk about how it works and what are the main features of the bundle.
How does symfony2 authentication work at all?
The Security component in a symphony in the beginning seems very complicated and confusing. But in fact, everything is very simple and logical.
Security consists of four basic elements: FirewallListeners, AuthenticationProviders, UserProviders, and AuthenticationManager.
FirewallListeners are implemented by the Firewall class. They chain the request at kernel.request. Their main task is to create an unauthenticated token that will be authenticated by the subsequent AuthenticatedProvider. They are also responsible for the serialization and deserialization of the token in a session ( ContextListener ), for the redirect of the user to https ( ChannelListener ), for the ACL ( AccessListener ).
For each firewall, symphony creates its own set of listener instances. This is done in SecurityExtension.
In the power of the listener, any manipulations with the session and the token are user logins, adding dynamic roles, changing the token, etc. etc.
Through the AuthenticationManager , the listeners interact with AuthenticationProviders . The main task of providers is to load the user via UserProvider and return an authenticated token - a token with at least one role.
The AuthenticationManager implements a loose relationship between the listeners and providers through the supports () method, which allows you to write universal listeners and providers.
All these components are glued together in SecurityExtension.
How does the bundle work?
Bundle adds another authentication step in the form of generating and downloading a user certificate.
The user is prompted to enter a secret word. It is necessary to encrypt the certificate before transferring it to the client and storing it on the server.
Also, the secret word is used when restoring the certificate, if the user lost it, came for another laptop or simply reinstalled the system. It is possible to disable this functionality and add your own logic for manual certificate recovery (last call, sms, last operation on the site, etc.)
After downloading and installing the certificate in the browser, the user gets full access. Bundle creates CertifiedUserToken , which is inherited from the standard UserNamePasswordToken, and also adds the ROLE_CERT_AUTHENTICATED_FULLY dynamic role, which is used in the above-mentioned AccessListener for access checking.
The main verification of the client certificate lies on the backend server (nginx, apache), which pass the result of the verification and the certificate to symfony. Variable names are configured in the config. file. Bundle only verifies the result of this check. Verification is performed using Symfony Expression Language and, by default, looks like:
cert["subject"]["CN"] == token.getUserName() && request.server.get("CLIENT_CERT_OK") === "SUCCESS"
In the context of the expression: cert (array in format openssl_x509_parse), the request object and the current token.
Since the server automatically validates the validFrom and validTo of the certificate, inactive accounts do not become a potential security gap over time.
The storage system ( zim_cert_auth.certificate_storage service) uses three main components: Formatter, Filters, Persister.
Formatter is responsible for converting an x509 resource to a storage format. Currently only PKCS12 formatter is implemented.
Filter allows you to apply any transformation before saving or retrieving.
Persister is responsible for the physical storage of certificates. Currently localfs and orm persists are implemented. Their purpose is clear from the title. There are plans to add a remotessh persister that will allow storing certificates on any other host using scp.
You can implement your services of formatters, persists, filters and define them in config.yml
Certificate Management
Bundle adds several cli commands to enable certificate management. At the moment there are two commands:
zim: cert: dump and zim: cert: remove.
Since the bundle is quite young, it may lack the functionality that is needed in real projects, so any suggestions on functionality, general work of the bundle, write in comments or on githabe, we will implement all the necessary features.
Thanks to all.
Source: https://habr.com/ru/post/270519/
All Articles