Symfony2 - security.yml中`anonymous.key`的用途

Question

I was setting up a Symfony2 application earlier that included routes that are both anonymous and restricted by HTTP BasicAuth. A basic firewall configuration using default values looks something like:

firewalls:
    main:
        anonymous: ~
        http_basic: ~

I could not find information on the options for the anonymous property, except in documentation for Symfony2's SecurityBundle Configuration, which presents a full default configuration .

The anonymous property appears to have only one property: key , as shown on line 206 of the default configuration:

some_firewall_listener:
    # ...
    anonymous:
        key: 4f954a0667e01

I dug into the core codebase and the accompanying unit tests a little, and it appears to be a constructor value for AnonymousToken and/or AnonymousAuthenticationListener but I haven't learned much from that so far.

There's a key property under remember_me also but I assume this has a different purpose.

I cannot find any other information that describes what this particular key property is, and what its purpose is. AnonymousToken::__construct() requires $key and $user arguments, so I assume this option is simply a manual override for a value that Symfony2 otherwise creates itself.

Can someone advise? Thanks :)

Answer 1

When authenticating an AnonymousToken , they key of the AnonymousAuthenticationProvider and the token are compared. When they don't match, authentication fails.

The same applies to the RememberMeToken and RememberMeAuthenticationProvider . When the key of the token and provider don't match, authentication fails.

The key is used to determine that the token currently authenticating was created by the application itself and not submitted by a malicious client. This mostly comes from the fact that Symfony Security is based on Spring Security (Java) and Java has RMI (Remote Method Invocation) support. From the Spring docs :

The use of the key property should not be regarded as providing any real security here. It is merely a book-keeping exercise. If you are sharing a ProviderManager which contains an AnonymousAuthenticationProvider in a scenario where it is possible for an authenticating client to construct the Authentication object (such as with RMI invocations), then a malicious client could submit an AnonymousAuthenticationToken which it had created itself (with chosen username and authority list). If the key is guessable or can be found out, then the token would be accepted by the anonymous provider. This isn't a problem with normal usage but if you are using RMI you would be best to use a customized ProviderManager which omits the anonymous provider rather than sharing the one you use for your HTTP authentication mechanisms.