Where does Symfony Security hydrate it’s AuthorizationCheckerInterface?

Where does Symfony Security hydrate it’s AuthorizationCheckerInterface?

I’m working on a three year old bit of software that relies on Symfony Security and sessions for it’s authorization. Recently, the company has made the request that in an attempt to bridge a bunch of related systems, they would like our application to manage it’s sessions using Javascript Web Tokens passed to it by another application’s security.

Not knowing exactly where to start, I started by looking at our SessionController.php file. This file just basically checks for a current session and returns pass/fail if there isn’t one. So it was a trivial matter to just switch to using the JWT, because all I needed to do was look for the cookie and decode it. This part seems to be working just fine.

What is not working fine is authorization: you can see the application, but even the login button shows you as not logged in. Basically: while I have a valid token, Symfony Security has not yet had a chance to hydrate it’s classes (I presume) in order to let isGranted() calls work correctly.

So the bottom line is that we’re no longer using Symfony to login – that’s being handled elsewhere. But when the application is called, it needs to somehow recognize that authentication has happened elsewhere and pick up with what it’s supposed to do.

The JWT token contains the user’s ID, so getting the user’s permissions seems like it should be a trivial matter. But what I don’t know is where the actual hydration of the Security classes is happening?

I’m happy to provide code samples, but since this is a whole application, I didn’t want to overload the post with what may end up being useless and very-lengthy code samples.

Here however is our security.yaml file, which I’m certain will be relevant:

# To get started with security, check out the documentation:
# http://symfony.com/doc/current/book/security.html
security:
    role_hierarchy:
        ROLE_USER: []
        ROLE_EDITOR: [ROLE_USER]
        ROLE_ADMIN: [ROLE_EDITOR]
        ROLE_SUPER_EDITOR: [ROLE_EDITOR]
        ROLE_SUPER_USER: [ROLE_ADMIN, ROLE_SUPER_EDITOR, ROLE_ALLOWED_TO_SWITCH]

    encoders:
        AppEntityUserUser:
            algorithm: auto

    # http://symfony.com/doc/current/book/security.html#where-do-users-come-from-user-providers
    providers:
        local_db_provider:
            entity:
                class: AppEntityUserUser

        in_memory:
            memory: ~

    firewalls:
        # disables authentication for assets and the profiler, adapt it according to your needs
        dev:
            pattern: ^/(_(profiler|wdt)|css|images|js)/
            security: false

        session_check:
            pattern: ^/session/check
            methods: [GET]
            security: false

        read_api:
            pattern: ^/api/
            methods: [GET]
            security: false

        main:
            pattern: ^/
            anonymous: true
            #stateless: true
            provider: local_db_provider
            user_checker: AppSecurityUserChecker

            logout:
                path: /logout
                target: salt_index

            guard:
                authenticators:
                    - AppSecurityLoginFormAuthenticator

    # with these settings you can restrict or allow access for different parts
    # of your application based on roles, ip, host or methods
    # http://symfony.com/doc/current/cookbook/security/access_control.htm
    # Note: Only the *first* access control that matches will be used
    access_control:
        #- { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: https }
        - { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/logout, roles: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/, roles: IS_AUTHENTICATED_ANONYMOUSLY }

Thank you.

Source: Symfony Questions

Leave a Reply

Your email address will not be published. Required fields are marked *