https://github.com/symfony/symfony-docs/blob/2.7/cookbook/security/custom_authentication_provider.rst

I feel as though the WSSE Example used in this page is with a good enough purpose to exist, but I feel as though this is mostly edge case and falls short on many of the common use procedures in crafting a custom auth provider.

The page even describes in footnotes:

Implement the :class:Symfony\\Component\\Security\\Core\\Authentication\\Token\\TokenInterface on any class to use as a token.

Could this be elaborated on?

These two notes highlight a (presumably) common usage scenario but opts to negate elaborating because it doesn't fit with WSSE's needs

Note

A class not used above, the :class:Symfony\\Component\\Security\\Http\\Firewall\\AbstractAuthenticationListener class, is a very useful base class which provides commonly needed functionality for security extensions. This includes maintaining the token in the session, providing success / failure handlers, login form URLs, and more. As WSSE does not require maintaining authentication sessions or login forms, it won't be used for this example.

I would like to see a proper, official, example or cookbook implementation of AbstractAuthenticationListener in a standard full example that demonstrates best practices and the where and the when's of Symfony's Authentication ecosystem everything applies.

Note

Returning prematurely from the listener is relevant only if you want to chain authentication providers (for example to allow anonymous users). If you want to forbid access to anonymous users and have a nice 403 error, you should set the status code of the response before returning.

Much like stated above, this note clearly informs me that the WSSE authentication is pretty different from standard requirements.

Note

A class not used in this example, :class:Symfony\\Bundle\\SecurityBundle\\DependencyInjection\\Security\\Factory\\AbstractFactory, is a very useful base class which provides commonly needed functionality for security factories. It may be useful when defining an authentication provider of a different type.

This does sound better, but the documentation lacks elaboration on best ways to implement this for, as described, "commonly needed functionality"

I understand that I can dig through the comments and connect the dots myself, and in most cases that would be ok. But Symfony's Security and Authentication system has many vague pieces to a big puzzle that isn't overly clear. In fact the documentation itself doesn't shy away from the fact that this component is technically challenging and tough to implement. I feel either replacing the WSSE example or providing an additional, in-depth example of how to create a custom authentication workflow from scratch would be far more beneficial overall.

Just for sake of brevity, I need to create an authentication flow that

1. Users are stored in a non-Doctrine compatible data store, and
2. Authenticates against a customized LDAP-like internal system.

I have the interaction layers with both, but now im trying to create an authentication system that still takes advantage of Symfony's security layer and use a custom Token. And that's where the WSSE example only gives me a small portion of the bigger picture.