djoos / EscapeWSSEAuthenticationBundle

Symfony bundle to implement WSSE authentication
http://symfony.com/doc/current/cookbook/security/custom_authentication_provider.html
137 stars 59 forks source link

WSSE authentication fails since upgrade to dev-master 0454e35 #32

Closed timtailor closed 10 years ago

timtailor commented 10 years ago

I am using the EscapeWSSEAuthenticationBundle with the FOSUserBundle as a provider.

Since updating from dev-master a06e4dd to dev-master 0454e35 i cannot authenticate. The log file says: app.DEBUG: WSSE authentication failed.

Before the composer update it was working fine. Any ideas what change between the two version could have such an impact?

Fixing the composer version to "escapestudios/wsse-authentication-bundle": "dev-master##a06e4dd" helps.

My security.yml is (regarding WSSE) as described on the readme page.


I compared the source code between the versions and found a change in the signature: protected function validateDigest($digest, $nonce, $created, $secret, $salt)

How do i have to modify my code so that it works with the new WSSE version?

djoos commented 10 years ago

Hi @timtailor,

do you override the validateDigest-method (and hence the Provider)? If not, the new version should work as well with FOSUser - it now takes the salt from the user to validate the digest.

Would you mind checking the generation of the digest vs. the expected digest? (which uses the user's password as secret and from now on also takes the user's salt into consideration)

Also: would you mind sending over your security.yml (WSSE-related bit only)?

Thanks in advance for your feedback!

Kind regards, David

timtailor commented 10 years ago

I basically used it out of the box (no override of validateDigest).

My android app retrieves the FOS user's salt from a public url, encodes his plain text password with his salt (sha512 and 5 iterations), then passes the WSSE Header (like http://www.teria.com/~koseki/tools/wssegen/) to the API url which is EscapeWSSE protected.

my security.yml (partly):


security:
    encoders:
        FOS\UserBundle\Model\UserInterface:
            algorithm:           sha512
            iterations:          5 
        Symfony\Component\Security\Core\User\User: plaintext

    providers:
        chain_provider:
            chain:
                providers: [in_memory, fos_userbundle]
        in_memory:
            # (etc.)
        fos_userbundle:
            id: fos_user.user_provider.username

    firewalls:
        dev:
            pattern:  ^/(_(profiler|wdt)|css|images|js)/
            security: false

        wsse_secured:
            pattern:   ^/(%allowed_locales%)/api/
            context: pmu
            wsse:
                realm: "Secured API" #identifies the set of resources to which the authentication information will apply (WWW-Authenticate)
                profile: "UsernameToken" #WSSE profile (WWW-Authenticate)
                lifetime: 3000 #lifetime of nonce
            anonymous: true

p.s. if you tell me how to do the "checking the generation of the digest vs. the expected digest" i will give it a try.

scr4tchy commented 10 years ago

Same here. The update broke my API. Sorry =/

security:
    providers:
        fos_userbundle:
            id: fos_user.user_manager

    encoders:
        "FOS\UserBundle\Model\UserInterface": sha512

    firewalls:
        wsse_secured:
            pattern:   ^/api/.*
            wsse:
                realm: "Secured API" #identifies the set of resources to which the authentication information will apply (WWW-Authenticate)
                profile: "UsernameToken" #WSSE profile (WWW-Authenticate)
                lifetime: 300 #lifetime of nonce

    access_decision_manager:
        strategy: unanimous

You can ask me to do some things, I'll do my best.

djoos commented 10 years ago

Hi,

I'm going to link this issue to #31 where @Fraktl is trying to achieve the same as you 2: FOSUser + WSSEAuth. FYI: there's no need to override the validateDigest-method in the Provider as highlighted by him in the thread - which is what I've solved in the latest commit!

Let's continue to get to the bottom of the issue over there? Thanks in advance!

Kind regards, David

scr4tchy commented 10 years ago

It worked will. It doesn't work anymore. It's all I can say...

I don't, as #31 does, create any method in a "SecurityController". I use directly the Header in calls, generated by http://www.teria.com/~koseki/tools/wssegen/ with my Username and FOS-Encrypted password. Like this:

X-WSSE: UsernameToken Username="Kedal", PasswordDigest="lhQnRw+EmKfA1rqHEnleWlnJJRg=", Nonce="ZWU3OTAzMDIyNDUzODA3ZQ==", Created="2014-01-24T19:07:29Z"
djoos commented 10 years ago

Hi @Mentalow,

"It worked will. It doesn't work anymore. It's all I can say..." :-D

I'm having a deeper look into it and start to realize I got carried away with @Fraktl's suggestion as the digest doesn't need a custom salt at all! Mea culpa - I'll fix it and will commit the fix ASAP.

Kind regards, David

timtailor commented 10 years ago

Hi David,

first off, thanks for your quick and extensive help here! Unfortunately i am still having the failing authoritzation.

Adding


firewalls:
    wsse_secured:
        #...
        wsse:
            #...
            encoder:
                algorithm: sha512
                encodeHashAsBase64: true #not *really* needed as defaults to true anyway (see https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/Encoder/MessageDigestPasswordEncoder.php)
                iterations: 5

didn't help. Now it fails with the new and old version. I will be on vacation after this weekend, but will try to investigate further afterwards and share any outcome here.

djoos commented 10 years ago

Hi Tim,

I'm sorry for the earlier suggestion to change the encoder: I got distracted with the stuff I spoke about in issue #31. So, please ignore my previous comment and take the suggested encoder-changes out...

It would be good if you could debug the issue some more on your end and push your findings to me here, AFAIK 8c683d4238762a22a8ad3a4e8d9cfe2a26443ac3 and f1bd591f4a3be8b21288d967ddb3b723db70fee3 should work like before the breaking change... Don't hesitate to push additional tests/findings in my direction, ok?

Have a great trip!

Kind regards, David

scr4tchy commented 10 years ago

Thanks a lot for your fix !

Best regards.