02 Jun 2014

security [第13天]

Security is a two-step process whose goal is to prevent a user from accessing a resource that they should not have access to.

In the first step of the process, the security system identifies who the user is by requiring the user to submit some sort of identification. This is called authentication, and it means that the system is trying to find out who you are.

Once the system knows who you are, the next step is to determine if you should have access to a given resource. This part of the process is called authorization, and it means that the system is checking to see if you have privileges to perform a certain action.

Since the best way to learn is to see an example, just imagine that you want to secure your application with HTTP Basic authentication.

Basic Example: HTTP Authentication¶

The Security component can be configured via your application configuration. In fact, most standard security setups are just a matter of using the right configuration. The following configuration tells Symfony to secure any URL matching /admin/* and to ask the user for credentials using basic HTTP authentication (i.e. the old-school username/password box):

YAML:

# app/config/security.yml
security:
    firewalls:
        secured_area:
            pattern:   ^/
            anonymous: ~
            http_basic:
                realm: "Secured Demo Area"

    access_control:
        - { path: ^/admin/, roles: ROLE_ADMIN }
        # Include the following line to also secure the /admin path itself
        # - { path: ^/admin$, roles: ROLE_ADMIN }

    providers:
        in_memory:
            memory:
                users:
                    ryan:  { password: ryanpass, roles: 'ROLE_USER' }
                    admin: { password: kitten, roles: 'ROLE_ADMIN' }

    encoders:
        Symfony\Component\Security\Core\User\User: plaintext

Tips:

A standard Symfony distribution separates the security configuration into a separate file (e.g. app/config/security.yml). If you don’t have a separate security file, you can put the configuration directly into your main config file (e.g. app/config/config.yml).

The end result of this configuration is a fully-functional security system that looks like the following:

There are two users in the system (ryan and admin);

Users authenticate themselves via the basic HTTP authentication prompt;

Any URL matching /admin/* is secured, and only the admin user can access it;

All URLs not matching /admin/* are accessible by all users (and the user is never prompted to log in).

Read this short summary about how security works and how each part of the configuration comes into play.

How Security Works: Authentication and Authorization¶

Symfony’s security system works by determining who a user is (i.e. authentication) and then checking to see if that user should have access to a specific resource or URL.

Firewalls (Authentication)¶

When a user makes a request to a URL that’s protected by a firewall, the security system is activated. The job of the firewall is to determine whether or not the user needs to be authenticated, and if they do, to send a response back to the user initiating the authentication process.

A firewall is activated when the URL of an incoming request matches the configured firewall’s regular expression pattern config value. In this example, the pattern (^/) will match every incoming request. The fact that the firewall is activated does not mean, however, that the HTTP authentication username and password box is displayed for every URL. For example, any user can access /foo without being prompted to authenticate.

Tips:

You can also match a request against other details of the request (e.g. host). For more information and examples read How to Restrict Firewalls to a Specific Request.

This works first because the firewall allows anonymous users via the anonymous configuration parameter. In other words, the firewall doesn’t require the user to fully authenticate immediately. And because no special role is needed to access /foo (under the access_control section), the request can be fulfilled without ever asking the user to authenticate.

If you remove the anonymous key, the firewall will always make a user fully authenticate immediately.

Access Controls (Authorization)¶

If a user requests /admin/foo, however, the process behaves differently. This is because of the access_control configuration section that says that any URL matching the regular expression pattern ^/admin (i.e. /admin or anything matching /admin/*) requires the ROLE_ADMIN role. Roles are the basis for most authorization: a user can access /admin/foo only if it has the ROLE_ADMIN role.

Like before, when the user originally makes the request, the firewall doesn’t ask for any identification. However, as soon as the access control layer denies the user access (because the anonymous user doesn’t have the ROLE_ADMIN role), the firewall jumps into action and initiates the authentication process. The authentication process depends on the authentication mechanism you’re using. For example, if you’re using the form login authentication method, the user will be redirected to the login page. If you’re using HTTP authentication, the user will be sent an HTTP 401 response so that the user sees the username and password box.

Til next time,
Xujiajun at 08:34