[
https://issues.apache.org/jira/browse/JAMES-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923088#comment-17923088
]
Felix commented on JAMES-4108:
------------------------------
For the sake of completion, I also tested whether `LOGIN` and `PLAIN` have
similar problems but they do not.
I had a look at the code to see what the difference is, particularly, I will
compare PLAIN with XOAUTH2:
Overview of the PLAIN handling:
* `doAUTH` calls `handlePlainContinuation`
* if there is an initial response, it will directly call `doPlainAuth`
* otherwise, it will push a new line handler that will call `doPlainAuth` when
the client sends a new line
* `doPlainAuth` extracts username and password and tries to authenticate the
user
* if that doesn't throw an error, a line handler is popped and the response is
returned
* if it throws an error, a negative response is returned
Overview of the XOAUTH2 handling:
* `doAUTH` calls `handleOauth2Continuation`
* if there is an initial response, it will directly call
`doOauth2Authentication`
* otherwise, it will push a new line handler that will call
`doOauth2Authentication` when the client sends a new line
* `doOauth2Authentication` effectively calls `doSasl`
* if that is successful, a positive response will be returned
* if it is unsuccessful `failSasl` will be called
* `failSasl` pushes a new line handler that will remove itself and returns a
negative response when the client sends a new line
The main difference to me seems to be that the line handler that consumes the
initial response (token) if it wasn't send with the first line, is never
popped. Hence all subsequent requests are treated as token and will fail.
`failSasl`'s behavior leads to an immediate response with an error and a
negative authentication result when the client sends a new line.
Hence, the fix should only be one `session.popLineHandler();`. I added this
line in the function `saslSuccess` (which is located in a different file) and
this seems to fix it. I am still a little bit confused because in the PLAIN and
LOGIN functions, a line handler is always popped on success. However, if the
credentials are sent with the first line, the server never adds an additional
line handler, so I would expect that one handler too much is popped in those
cases. But so far I didn't notice any signs of that in the subsequent server
responses.
> James stuck in authentication loop after successful XOAUTH2 authentication
> --------------------------------------------------------------------------
>
> Key: JAMES-4108
> URL: https://issues.apache.org/jira/browse/JAMES-4108
> Project: James Server
> Issue Type: Bug
> Components: SMTPServer
> Affects Versions: 3.9.0
> Reporter: Felix
> Priority: Major
>
> I have set up a JAMES server with XOAUTH2.
> When I authenticate at the SMTP server with `AUTH XOAUTH2 <token>`,
> everything works fine.
> When I first send `AUTH XOAUTH2` (empty initial response), the server answers
> with `334` (as it should). I then send my token after that and the server
> responds `235 Authentication successful.`. But no matter what I send after
> that (it does not even have to be a valid command), the server responds
> alternately with
> 1. `334
> eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJlbWFpbCIsInNjaGVtZXMiOiJodHRwczovLzxkb21haW4+L2F1dGgvcmVhbG1zLzxyZWFsbT4vLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24ifQ==`
> (own domain removed), decoded: `
> {"status":"invalid_token","scope":"email","schemes":"https://<domain>/auth/realms/<realm>/.well-known/openid-configuration"}
> ` and
> 2. `535 Authentication Failed`
> It seems like - although there was a successful authentication - the server
> seems to still be stuck in the XOAUTH2 authentication handler.
> I suspect that this is related to a recent bug (fixed in
> [https://github.com/apache/james-project/pull/2428]) where sending an empty
> initial response (only `AUTH XOAUTH2`) to the SMTP server resulted in a Null
> Pointer Exception.
> The IMAP server does not have these problems (no exception and no auth loop).
> Release 3.8.2 still has the null pointer exception (does not include the fix)
> but does not have the authentication loop (or it cannot be triggered because
> of the exception).
> Reproduce:
> - Clone and checkout
> [https://github.com/apache/james-project/commit/b3b75b5b5343d8a3d838617addab3e9c3b40e5d4]
> (current master at time of writing)
> - Build project with `mvn clean install -Dmaven.javadoc.skip=true
> -DskipTests`
> - Copy sample configuration from repo:
> [https://github.com/apache/james-project/tree/b3b75b5b5343d8a3d838617addab3e9c3b40e5d4/server/apps/jpa-app/sample-configuration]
> - Remove imap servers in `imapserver.xml` (not relevant here)
> - Remove lmtp server in `lmtpserver.xml` (not relevant here)
> - Remove managesieve server in `managesieveserver.xml` (not relevant here)
> - Remove pop3 server in `pop3server.xml` (not relevant here)
> - Remove all smtp servers except the port 25 one in `smtpserver.xml` (the
> others are not relevant here)
> - Change port of smtp server from 25 to 2525 in `smtpserver.xml` (enables
> starting without evelated privileges)
> - Configure the auth section of the smtp server in `smtpserver.xml` (see
> below)
> - Remove `authorizedAddresses` from the `smtpserver.xml` (I want to showcase
> OIDC authentication here)
> - Change the log file from `/logs/james.log` to `./james.log` in
> `logback.xml`
> - Add domain that will be in the token as the default domain in
> `domainlist.xml`
> - Start server with `java -javaagent:james-server-jpa
> app.lib/openjpa-4.0.0.jar -Dworking.directory=.
> -Djdk.tls.ephemeralDHKeySize=2048
> -Dlogback.configurationFile=conf/logback.xml -jar james-server-jpa-app.jar
> --generate-keystore`
> My full SMTP config (comments from the sample config removed):
> {code:xml}
> <smtpservers>
> <smtpserver enabled="true">
> <jmxName>smtpserver-global</jmxName>
> <bind>0.0.0.0:2525</bind>
> <connectionBacklog>200</connectionBacklog>
> <tls socketTLS="false" startTLS="false">
> <keystore>file://conf/keystore</keystore>
> <keystoreType>PKCS12</keystoreType>
> <secret>james72laBalle</secret>
>
> <provider>org.bouncycastle.jce.provider.BouncyCastleProvider</provider>
> <algorithm>SunX509</algorithm>
> </tls>
> <connectiontimeout>360</connectiontimeout>
> <connectionLimit>0</connectionLimit>
> <connectionLimitPerIP>0</connectionLimitPerIP>
> <auth>
> <announce>always</announce>
> <plainAuthEnabled>true</plainAuthEnabled>
> <requireSSL>false</requireSSL>
> <oidc>
>
> <oidcConfigurationURL>https://<domain>/auth/realms/<realm>/.well-known/openid-configuration</oidcConfigurationURL>
>
> <jwksURL>https://<domain>/auth/realms/<realm>/protocol/openid-connect/certs</jwksURL>
> <claim>sub-email</claim>
> <scope>email</scope>
> </oidc>
> </auth>
> <verifyIdentity>true</verifyIdentity>
> <maxmessagesize>0</maxmessagesize>
> <addressBracketsEnforcement>true</addressBracketsEnforcement>
> <smtpGreeting>Apache JAMES awesome SMTP Server</smtpGreeting>
> <handlerchain>
> <handler
> class="org.apache.james.smtpserver.fastfail.ValidRcptHandler"/>
> <handler
> class="org.apache.james.smtpserver.CoreCmdHandlerLoader"/>
> </handlerchain>
> </smtpserver>
> </smtpservers>
> {code}
> My platform (output von `mvn --version`):
> {code:java}
> Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> Maven home: /usr/share/java/maven
> Java version: 21.0.6, vendor: Arch Linux, runtime:
> /usr/lib/jvm/java-21-openjdk
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "6.12.10-arch1-1", arch: "amd64", family: "unix"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
