You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "btellier@apache.org" <bt...@apache.org> on 2021/12/02 04:41:38 UTC
Authentication in James: Enable/require/disable OpenID for JMAP, IMAP and SMTP
|Hello Jamers! As part of our work at Linagora, we are looking toward -
better integrating James within our product suite and for us this means
support "Single Sign On" and "Single Log Out" for JMAP following the
OpenId connect standard [0]. - Improving security standards used to
operate James. (We have a growing activity within the health care
market, sensible to security arguments) Regarding security standards we
should ideally: - Be able to NOT advertise AUTH / LOGIN capabilities of
unencrypted channels (Correspond to IMAP plainAuthDissallowed but
generalized to other protocols) - Be able to require OAUTH/OIDC
authentication for all protocols (IMAP, SMTP, JMAP) - this is what some
of the health care providers we spoke to desired to do. - For our
collaborative suite usage, while OIDC only for JMAP makes sense, we
still wish to maintain PLAIN AUTH for IMAP and SMTP. - Of course
settings for regular users not interested in OIDC should not change (no
breaking changes, OIDC adoption is opt-in only). As such we propose
ourselves to: - Contribute IMAP and SMTP SASL OAUTH extension described
in [RFC-7628] - Modularize JMAP authentication mechanisms (letting the
admin choose which one she wishes to use) - Enable authentication
through a header mechanism eg `X-USER: btellier@apache.org`, which can
be used to delegate OIDC authentication through a third party API
gateway. We have Krackend [1] in mind. - Share documentation and a
docker-compose of OIDC setup for IMAP, SMTP and JMAP in
https://github.com/apache/james-project/tree/master/examples/oidc. This
would include: - A LDAP still used by James UsersRepository. Provisioned
with a testing user. - A pre-configured Keycloack [2] OpenID connect
provider. - A pre-configured Krakend API gateway proxying JMAP - And
finally a James server configured to only accept OIDC as an
authentication mechanism for IMAP, SMTP and JMAP. - Unit tests for
existing IMAP `plainAuthDissallowed` configuration parameter. Finally
this is a good opportunity to restructure authentication related
settings in imapserver.xml and smtpserver.xml file. Here are proposals
for both files: [imapserver.xml] ---- <imapserver enabled="true">
<jmxName>imapserver-ssl</jmxName> <bind>0.0.0.0:993</bind> <tls
socketTLS="true" startTLS="false">
<privateKey>file://conf/private.key</privateKey>
<certificates>file://conf/certs.self-signed.csr</certificates> </tls>
<!-- ... --> <authentication>
<plainAuthEnabled>true|false</plainAuthEnabled> <!-- defaults to true
--> <oauth> <!-- ommiting this block would disable oauth. All fields are
compulsory --> <publicKey>file://conf/imapJWT.pub</publicKey>
<oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
<claim>mailAddress</claim> </oauth> </authentication> </imapserver> ----
[smtpserver.xml] ---- <smtpserver enabled="true">
<jmxName>smtpserver-ssl</jmxName> <bind>0.0.0.0:465</bind> <tls
socketTLS="true" startTLS="false">
<privateKey>file://conf/private.key</privateKey>
<certificates>file://conf/certs.self-signed.csr</certificates> </tls>
<!--- ... --> <requireAuthForRelay>true|false</requireAuthForRelay>
<authentication> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
defaults to true --> <oauth> <!-- ommiting this block would disable
oauth. All fields are compulsory -->
<publicKey>file://conf/imapJWT.pub</publicKey>
<oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
<claim>mailAddress</claim> </oauth> </authentication> </smtpserver> ----
You can see that: - The `plainAuthDissallowed` parameter is proposed to
be renamed to `auth.requireSSL`. (of course we should support fallback
NOT to have a breaking change) - `auth.plainAuthEnabled` enable turning
on/off plain auth, which allows having OIDC only mechanism. -
`auth.requireSSL` will be generalized to SMTP. - In SMTP `requireAuth`
setting is very misleading as it rather is `requireAuthForRelay`. I
propose we rename this configuration option (of course we should support
fallback NOT to have a breaking change). Here is the implementation
strategies we would follow: - For JMAP have Krakend doing all the hard
job for us, and use a dedicated header to carry the information over to
James. - Our code contributions aims at easing such a setup (that would
only require configuration) - Provide an informative example using
krakend. We understand that this choice is ours, yet sharing it could
allow reuse or similar setup - If some people wishes to write an OIDC
authentication strategy directly in James then they perfectly can!
(Reusing the modularization of JMAP authentication strategies we would
provide). - For IMAP and SMTP then we proposes to check the bearer
payload against a statically configured public key for these protocols.
(Sadly there is no API gateway for those protocols) - Drawbacks includes
no revocation of access tokens (once it's signed it is always valid),
revocation do not shut down existing connections authenticated with the
revocated token, and key rotation would require reconfiguration and
reboot. - One alternative would be to systematically ask the OpenID
server to validate the bearer. This might be acceptable as IMAP and SMTP
are long lived protocols that do not often establish new connections.
While this do not change anything regarding already opened connection
management, this solves revocation and public key rotation at the price
of exposing more the identity provider... - Of course James could expose
a back-channel for token invalidation, stored in some kind of shared
storage, but this complexify things a bit. - Similarily HTTP calls could
be made to get the JWKS key (and cache it) but this also complexify the
picture quite a bit... I am deeply convinced this efforts would help
James admins more control over exposed authentication mechanisms and
ultimately offer state of the art authentication options. This should
help James check a few more boxes in security reviews and eventually
ease adoption! Useful links: [0] OpenId spec:
https://openid.net/specs/openid-connect-core-1_0.html [1] Krakend:
https://www.krakend.io/ [2] Keycloack: https://www.keycloak.org/
[RFC-7628] SASL OATH mechanism for SMTP and IMAP:
https://datatracker.ietf.org/doc/html/rfc7628 Krakend configured with
keycloack: https://www.krakend.io/docs/authorization/keycloak/ Krakend
configured with token revocation:
https://www.krakend.io/docs/authorization/revoking-tokens/ Best regards,
Benoit TELLIER|
Re: Authentication in James: Enable/require/disable OpenID for JMAP, IMAP and SMTP
Posted by Rene Cordier <rc...@apache.org>.
+1,
Rene.
On 02/12/2021 11:56, btellier@linagora.com wrote:
> Hopefully rendered correctly in plain text...
>
> -----------------------------------------
>
> Hello Jamers!
>
> As part of my work at Linagora, we are looking toward
> - better integrating James within our product suite and for us this
> means support "Single Sign On" and "Single Log Out" for JMAP following
> the OpenId connect standard [0].
> - Improving security standards used to opperate James. (We have a
> growing activity within the health care market, sensible to security
> arguments)
>
> Regarding security standards we should ideally:
> - Be able to NOT advertise AUTH / LOGIN capabilities of unencrypted
> channels (Correspond to IMAP plainAuthDissallowed but generalized to
> other protocols)
> - Be able to require OAUTH/OIDC authentication for all protocols (IMAP,
> SMTP, JMAP) - this is what some of the health care providers we spoke to
> desired to do.
> - For our collaborative suite usage, while OIDC only for JMAP makes
> sense, we still wish to maintain PLAIN AUTH for IMAP and SMTP.
> - Of course settings for regular users not interested in OIDC should
> not change (no breaking changes, OIDC adoption is opt-in only).
>
> As such we propose ourselves to:
> - Contribute IMAP and SMTP SASL OAUTH extension described in [RFC-7628]
> - Modularize JMAP authentication mechanisms (letting the admin choose
> which one she wishes to use)
> - Enable authentication through a header mechanism eg `X-USER:
> btellier@apache.org`, which can be used to delegate OIDC authentication
> through a third party API gateway. We have Krackend [1] in mind.
> - Share documentation and a docker-compose of OIDC setup for IMAP, SMTP
> and JMAP in
> https://github.com/apache/james-project/tree/master/examples/oidc. This
> would include:
> - A LDAP still used by James UsersRepository. Provisionned with a
> testing user.
> - A pre-configured Keycloack [2] OpenID connect provider.
> - A pre-configured Krakend API gateway proxying JMAP
> - And finally a James server configured to only accept OIDC as an
> authentication mechanism for IMAP, SMTP and JMAP.
> - Unit tests for existing IMAP `plainAuthDissallowed` configuration
> parameter.
>
> Finally this is a good opportunity to restructure authentication related
> settings in imapserver.xml and smtpserver.xml file.
>
> Here are proposals for both files:
>
> [imapserver.xml]
> ----
> <imapserver enabled="true">
> <jmxName>imapserver-ssl</jmxName>
> <bind>0.0.0.0:993</bind>
> <tls socketTLS="true" startTLS="false">
> <privateKey>file://conf/private.key</privateKey>
> <certificates>file://conf/certs.self-signed.csr</certificates>
> </tls>
> <!-- ... -->
> <authentication>
> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
> defaults to true -->
> <oauth> <!-- ommiting this block would disable oauth. All
> fields are compulsory -->
> <publicKey>file://conf/imapJWT.pub</publicKey>
>
> <oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
> <claim>mailAddress</claim>
> </oauth>
> </authentication>
> </imapserver>
> ----
>
> [smtpserver.xml]
> ----
> <smtpserver enabled="true">
> <jmxName>smtpserver-ssl</jmxName>
> <bind>0.0.0.0:465</bind>
> <tls socketTLS="true" startTLS="false">
> <privateKey>file://conf/private.key</privateKey>
> <certificates>file://conf/certs.self-signed.csr</certificates>
> </tls>
> <!--- ... -->
> <requireAuthForRelay>true|false</requireAuthForRelay>
> <authentication>
> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
> defaults to true -->
> <oauth> <!-- ommiting this block would disable oauth. All
> fields are compulsory -->
> <publicKey>file://conf/imapJWT.pub</publicKey>
>
> <oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
> <claim>mailAddress</claim>
> </oauth>
> </authentication>
> </smtpserver>
> ----
>
> You can see that:
> - The `plainAuthDissallowed` parameter is proposed to be renamed to
> `auth.requireSSL`. (of course we should support fallback NOT to have a
> breaking change)
> - `auth.plainAuthEnabled` enable turning on/off plain auth, which
> allows having OIDC only mechanism.
> - `auth.requireSSL` will be generalized to SMTP.
> - In SMTP `requireAuth` setting is very misleading as it rather is
> `requireAuthForRelay`. I propose we rename this configuration option (of
> course we should support fallback NOT to have a breaking change).
>
> Here is the implementation strategies we would follow:
>
> - For JMAP have Krakend doing all the hard job for us, and use a
> dedicated header to carry the information over to James.
> - Our code contributions aims at easing such a setup (that would only
> require configuration)
> - Provide an informative example using krakend. We understand that
> this choice is ours, yet sharing it could allow reuse or similar setup
> - If some people wishes to write an OIDC authentication strategy
> directly in James then they perfectly can! (Reusing the modularization
> of JMAP authentication strategies we would provide).
>
> - For IMAP and SMTP then we proposes to check the bearer payload
> against a statically configured public key for these protocols. (Sadly
> there is no API gateway for those protocols)
> - Drawbacks includes no revocation of access tokens (once it's signed
> it is always valid), revocation do not shut down existing connections
> authenticated with the revocated token, and key rotation would require
> reconfiguration and reboot.
> - One alternative would be to systematically ask the OpenID server to
> validate the bearer. This might be acceptable as IMAP and SMTP are long
> lived protocols that do not often establish new connections. While this
> do not change anything regarding already opened connection management,
> this solves revocation and public key rotation at the price of exposing
> more the identity provider...
> - Of course James could expose a back-channel for token invalidation,
> stored in some kind of shared storage, but this complexify things a bit.
> - Similarily HTTP calls could be made to get the JWKS key (and cache
> it) but this also complexify the picture quite a bit...
>
> I am deeply convinced this efforts would help James admins more control
> over exposed authentication mechanisms and ultimately offer state of the
> art authentication options. This should help James check a few more
> boxes in security reviews and eventually ease adoption!
>
> Useful links:
>
> [0] OpenId spec: https://openid.net/specs/openid-connect-core-1_0.html
>
>
> [1] Krakend: https://www.krakend.io/
> [2] Keycloack: https://www.keycloak.org/
> [RFC-7628] SASL OATH mechanism for SMTP and IMAP:
> https://datatracker.ietf.org/doc/html/rfc7628
> Krakend configured with keycloack:
> https://www.krakend.io/docs/authorization/keycloak/
> Krakend configured with token revocation:
> https://www.krakend.io/docs/authorization/revoking-tokens/
>
> Best regards,
>
> Benoit TELLIER
>
> On 02/12/2021 11:41, btellier@apache.org wrote:
>> |Hello Jamers! As part of our work at Linagora, we are looking toward -
>> better integrating James within our product suite and for us this means
>> support "Single Sign On" and "Single Log Out" for JMAP following the
>> OpenId connect standard [0]. - Improving security standards used to
>> operate James. (We have a growing activity within the health care
>> market, sensible to security arguments) Regarding security standards we
>> should ideally: - Be able to NOT advertise AUTH / LOGIN capabilities of
>> unencrypted channels (Correspond to IMAP plainAuthDissallowed but
>> generalized to other protocols) - Be able to require OAUTH/OIDC
>> authentication for all protocols (IMAP, SMTP, JMAP) - this is what some
>> of the health care providers we spoke to desired to do. - For our
>> collaborative suite usage, while OIDC only for JMAP makes sense, we
>> still wish to maintain PLAIN AUTH for IMAP and SMTP. - Of course
>> settings for regular users not interested in OIDC should not change (no
>> breaking changes, OIDC adoption is opt-in only). As such we propose
>> ourselves to: - Contribute IMAP and SMTP SASL OAUTH extension described
>> in [RFC-7628] - Modularize JMAP authentication mechanisms (letting the
>> admin choose which one she wishes to use) - Enable authentication
>> through a header mechanism eg `X-USER: btellier@apache.org`, which can
>> be used to delegate OIDC authentication through a third party API
>> gateway. We have Krackend [1] in mind. - Share documentation and a
>> docker-compose of OIDC setup for IMAP, SMTP and JMAP in
>> https://github.com/apache/james-project/tree/master/examples/oidc. This
>> would include: - A LDAP still used by James UsersRepository. Provisioned
>> with a testing user. - A pre-configured Keycloack [2] OpenID connect
>> provider. - A pre-configured Krakend API gateway proxying JMAP - And
>> finally a James server configured to only accept OIDC as an
>> authentication mechanism for IMAP, SMTP and JMAP. - Unit tests for
>> existing IMAP `plainAuthDissallowed` configuration parameter. Finally
>> this is a good opportunity to restructure authentication related
>> settings in imapserver.xml and smtpserver.xml file. Here are proposals
>> for both files: [imapserver.xml] ---- <imapserver enabled="true">
>> <jmxName>imapserver-ssl</jmxName> <bind>0.0.0.0:993</bind> <tls
>> socketTLS="true" startTLS="false">
>> <privateKey>file://conf/private.key</privateKey>
>> <certificates>file://conf/certs.self-signed.csr</certificates> </tls>
>> <!-- ... --> <authentication>
>> <plainAuthEnabled>true|false</plainAuthEnabled> <!-- defaults to true
>> --> <oauth> <!-- ommiting this block would disable oauth. All fields are
>> compulsory --> <publicKey>file://conf/imapJWT.pub</publicKey>
>> <oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
>> <claim>mailAddress</claim> </oauth> </authentication> </imapserver> ----
>> [smtpserver.xml] ---- <smtpserver enabled="true">
>> <jmxName>smtpserver-ssl</jmxName> <bind>0.0.0.0:465</bind> <tls
>> socketTLS="true" startTLS="false">
>> <privateKey>file://conf/private.key</privateKey>
>> <certificates>file://conf/certs.self-signed.csr</certificates> </tls>
>> <!--- ... --> <requireAuthForRelay>true|false</requireAuthForRelay>
>> <authentication> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
>> defaults to true --> <oauth> <!-- ommiting this block would disable
>> oauth. All fields are compulsory -->
>> <publicKey>file://conf/imapJWT.pub</publicKey>
>> <oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
>> <claim>mailAddress</claim> </oauth> </authentication> </smtpserver> ----
>> You can see that: - The `plainAuthDissallowed` parameter is proposed to
>> be renamed to `auth.requireSSL`. (of course we should support fallback
>> NOT to have a breaking change) - `auth.plainAuthEnabled` enable turning
>> on/off plain auth, which allows having OIDC only mechanism. -
>> `auth.requireSSL` will be generalized to SMTP. - In SMTP `requireAuth`
>> setting is very misleading as it rather is `requireAuthForRelay`. I
>> propose we rename this configuration option (of course we should support
>> fallback NOT to have a breaking change). Here is the implementation
>> strategies we would follow: - For JMAP have Krakend doing all the hard
>> job for us, and use a dedicated header to carry the information over to
>> James. - Our code contributions aims at easing such a setup (that would
>> only require configuration) - Provide an informative example using
>> krakend. We understand that this choice is ours, yet sharing it could
>> allow reuse or similar setup - If some people wishes to write an OIDC
>> authentication strategy directly in James then they perfectly can!
>> (Reusing the modularization of JMAP authentication strategies we would
>> provide). - For IMAP and SMTP then we proposes to check the bearer
>> payload against a statically configured public key for these protocols.
>> (Sadly there is no API gateway for those protocols) - Drawbacks includes
>> no revocation of access tokens (once it's signed it is always valid),
>> revocation do not shut down existing connections authenticated with the
>> revocated token, and key rotation would require reconfiguration and
>> reboot. - One alternative would be to systematically ask the OpenID
>> server to validate the bearer. This might be acceptable as IMAP and SMTP
>> are long lived protocols that do not often establish new connections.
>> While this do not change anything regarding already opened connection
>> management, this solves revocation and public key rotation at the price
>> of exposing more the identity provider... - Of course James could expose
>> a back-channel for token invalidation, stored in some kind of shared
>> storage, but this complexify things a bit. - Similarily HTTP calls could
>> be made to get the JWKS key (and cache it) but this also complexify the
>> picture quite a bit... I am deeply convinced this efforts would help
>> James admins more control over exposed authentication mechanisms and
>> ultimately offer state of the art authentication options. This should
>> help James check a few more boxes in security reviews and eventually
>> ease adoption! Useful links: [0] OpenId spec:
>> https://openid.net/specs/openid-connect-core-1_0.html [1] Krakend:
>> https://www.krakend.io/ [2] Keycloack: https://www.keycloak.org/
>> [RFC-7628] SASL OATH mechanism for SMTP and IMAP:
>> https://datatracker.ietf.org/doc/html/rfc7628 Krakend configured with
>> keycloack: https://www.krakend.io/docs/authorization/keycloak/ Krakend
>> configured with token revocation:
>> https://www.krakend.io/docs/authorization/revoking-tokens/ Best regards,
>> Benoit TELLIER|
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Authentication in James: Enable/require/disable OpenID for JMAP, IMAP and SMTP
Posted by "btellier@apache.org" <bt...@apache.org>.
Hello,
We have been putting together an ADR on this topic.
https://github.com/apache/james-project/pull/778
We have been finding this simple library allowing to easily get the
public key out of a JWKS endpoint: https://github.com/auth0/jwks-rsa-java
Using it would enable a dynamic management of OIDC public signing keys
for IMAP and SMTP. We would replace in the configuration static public
keys by the jwks endpoint. As such the xmls would become:
[imapserver.xml]
----
<imapserver enabled="true">
<jmxName>imapserver-ssl</jmxName>
<bind>0.0.0.0:993</bind>
<tls socketTLS="true" startTLS="false">
<privateKey>file://conf/private.key</privateKey>
<certificates>file://conf/certs.self-signed.csr</certificates>
</tls>
<!-- ... -->
<authentication>
<plainAuthEnabled>true|false</plainAuthEnabled> <!--
defaults to true -->
<oauth> <!-- ommiting this block would disable oauth. All
fields are compulsory -->
<jwksURL>https://example.com/jwks</jwksURL>
<oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
<claim>mailAddress</claim>
</oauth>
</authentication>
</imapserver>
----
[smtpserver.xml]
----
<smtpserver enabled="true">
<jmxName>smtpserver-ssl</jmxName>
<bind>0.0.0.0:465</bind>
<tls socketTLS="true" startTLS="false">
<privateKey>file://conf/private.key</privateKey>
<certificates>file://conf/certs.self-signed.csr</certificates>
</tls>
<!--- ... -->
<requireAuthForRelay>true|false</requireAuthForRelay>
<authentication>
<plainAuthEnabled>true|false</plainAuthEnabled> <!--
defaults to true -->
<oauth> <!-- ommiting this block would disable oauth. All
fields are compulsory -->
<jwksURL>https://example.com/jwks</jwksURL>
<oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
<claim>mailAddress</claim>
</oauth>
</authentication>
</smtpserver>
----
Cheers,
Benoit
On 02/12/2021 11:56, btellier@linagora.com wrote:
> Hopefully rendered correctly in plain text...
>
> -----------------------------------------
>
> Hello Jamers!
>
> As part of my work at Linagora, we are looking toward
> - better integrating James within our product suite and for us this
> means support "Single Sign On" and "Single Log Out" for JMAP following
> the OpenId connect standard [0].
> - Improving security standards used to opperate James. (We have a
> growing activity within the health care market, sensible to security
> arguments)
>
> Regarding security standards we should ideally:
> - Be able to NOT advertise AUTH / LOGIN capabilities of unencrypted
> channels (Correspond to IMAP plainAuthDissallowed but generalized to
> other protocols)
> - Be able to require OAUTH/OIDC authentication for all protocols (IMAP,
> SMTP, JMAP) - this is what some of the health care providers we spoke to
> desired to do.
> - For our collaborative suite usage, while OIDC only for JMAP makes
> sense, we still wish to maintain PLAIN AUTH for IMAP and SMTP.
> - Of course settings for regular users not interested in OIDC should
> not change (no breaking changes, OIDC adoption is opt-in only).
>
> As such we propose ourselves to:
> - Contribute IMAP and SMTP SASL OAUTH extension described in [RFC-7628]
> - Modularize JMAP authentication mechanisms (letting the admin choose
> which one she wishes to use)
> - Enable authentication through a header mechanism eg `X-USER:
> btellier@apache.org`, which can be used to delegate OIDC authentication
> through a third party API gateway. We have Krackend [1] in mind.
> - Share documentation and a docker-compose of OIDC setup for IMAP, SMTP
> and JMAP in
> https://github.com/apache/james-project/tree/master/examples/oidc. This
> would include:
> - A LDAP still used by James UsersRepository. Provisionned with a
> testing user.
> - A pre-configured Keycloack [2] OpenID connect provider.
> - A pre-configured Krakend API gateway proxying JMAP
> - And finally a James server configured to only accept OIDC as an
> authentication mechanism for IMAP, SMTP and JMAP.
> - Unit tests for existing IMAP `plainAuthDissallowed` configuration
> parameter.
>
> Finally this is a good opportunity to restructure authentication related
> settings in imapserver.xml and smtpserver.xml file.
>
> Here are proposals for both files:
>
> [imapserver.xml]
> ----
> <imapserver enabled="true">
> <jmxName>imapserver-ssl</jmxName>
> <bind>0.0.0.0:993</bind>
> <tls socketTLS="true" startTLS="false">
> <privateKey>file://conf/private.key</privateKey>
> <certificates>file://conf/certs.self-signed.csr</certificates>
> </tls>
> <!-- ... -->
> <authentication>
> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
> defaults to true -->
> <oauth> <!-- ommiting this block would disable oauth. All
> fields are compulsory -->
> <publicKey>file://conf/imapJWT.pub</publicKey>
>
> <oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
> <claim>mailAddress</claim>
> </oauth>
> </authentication>
> </imapserver>
> ----
>
> [smtpserver.xml]
> ----
> <smtpserver enabled="true">
> <jmxName>smtpserver-ssl</jmxName>
> <bind>0.0.0.0:465</bind>
> <tls socketTLS="true" startTLS="false">
> <privateKey>file://conf/private.key</privateKey>
> <certificates>file://conf/certs.self-signed.csr</certificates>
> </tls>
> <!--- ... -->
> <requireAuthForRelay>true|false</requireAuthForRelay>
> <authentication>
> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
> defaults to true -->
> <oauth> <!-- ommiting this block would disable oauth. All
> fields are compulsory -->
> <publicKey>file://conf/imapJWT.pub</publicKey>
>
> <oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
> <claim>mailAddress</claim>
> </oauth>
> </authentication>
> </smtpserver>
> ----
>
> You can see that:
> - The `plainAuthDissallowed` parameter is proposed to be renamed to
> `auth.requireSSL`. (of course we should support fallback NOT to have a
> breaking change)
> - `auth.plainAuthEnabled` enable turning on/off plain auth, which
> allows having OIDC only mechanism.
> - `auth.requireSSL` will be generalized to SMTP.
> - In SMTP `requireAuth` setting is very misleading as it rather is
> `requireAuthForRelay`. I propose we rename this configuration option (of
> course we should support fallback NOT to have a breaking change).
>
> Here is the implementation strategies we would follow:
>
> - For JMAP have Krakend doing all the hard job for us, and use a
> dedicated header to carry the information over to James.
> - Our code contributions aims at easing such a setup (that would only
> require configuration)
> - Provide an informative example using krakend. We understand that
> this choice is ours, yet sharing it could allow reuse or similar setup
> - If some people wishes to write an OIDC authentication strategy
> directly in James then they perfectly can! (Reusing the modularization
> of JMAP authentication strategies we would provide).
>
> - For IMAP and SMTP then we proposes to check the bearer payload
> against a statically configured public key for these protocols. (Sadly
> there is no API gateway for those protocols)
> - Drawbacks includes no revocation of access tokens (once it's signed
> it is always valid), revocation do not shut down existing connections
> authenticated with the revocated token, and key rotation would require
> reconfiguration and reboot.
> - One alternative would be to systematically ask the OpenID server to
> validate the bearer. This might be acceptable as IMAP and SMTP are long
> lived protocols that do not often establish new connections. While this
> do not change anything regarding already opened connection management,
> this solves revocation and public key rotation at the price of exposing
> more the identity provider...
> - Of course James could expose a back-channel for token invalidation,
> stored in some kind of shared storage, but this complexify things a bit.
> - Similarily HTTP calls could be made to get the JWKS key (and cache
> it) but this also complexify the picture quite a bit...
>
> I am deeply convinced this efforts would help James admins more control
> over exposed authentication mechanisms and ultimately offer state of the
> art authentication options. This should help James check a few more
> boxes in security reviews and eventually ease adoption!
>
> Useful links:
>
> [0] OpenId spec: https://openid.net/specs/openid-connect-core-1_0.html
>
>
> [1] Krakend: https://www.krakend.io/
> [2] Keycloack: https://www.keycloak.org/
> [RFC-7628] SASL OATH mechanism for SMTP and IMAP:
> https://datatracker.ietf.org/doc/html/rfc7628
> Krakend configured with keycloack:
> https://www.krakend.io/docs/authorization/keycloak/
> Krakend configured with token revocation:
> https://www.krakend.io/docs/authorization/revoking-tokens/
>
> Best regards,
>
> Benoit TELLIER
>
> On 02/12/2021 11:41, btellier@apache.org wrote:
>> |Hello Jamers! As part of our work at Linagora, we are looking toward -
>> better integrating James within our product suite and for us this means
>> support "Single Sign On" and "Single Log Out" for JMAP following the
>> OpenId connect standard [0]. - Improving security standards used to
>> operate James. (We have a growing activity within the health care
>> market, sensible to security arguments) Regarding security standards we
>> should ideally: - Be able to NOT advertise AUTH / LOGIN capabilities of
>> unencrypted channels (Correspond to IMAP plainAuthDissallowed but
>> generalized to other protocols) - Be able to require OAUTH/OIDC
>> authentication for all protocols (IMAP, SMTP, JMAP) - this is what some
>> of the health care providers we spoke to desired to do. - For our
>> collaborative suite usage, while OIDC only for JMAP makes sense, we
>> still wish to maintain PLAIN AUTH for IMAP and SMTP. - Of course
>> settings for regular users not interested in OIDC should not change (no
>> breaking changes, OIDC adoption is opt-in only). As such we propose
>> ourselves to: - Contribute IMAP and SMTP SASL OAUTH extension described
>> in [RFC-7628] - Modularize JMAP authentication mechanisms (letting the
>> admin choose which one she wishes to use) - Enable authentication
>> through a header mechanism eg `X-USER: btellier@apache.org`, which can
>> be used to delegate OIDC authentication through a third party API
>> gateway. We have Krackend [1] in mind. - Share documentation and a
>> docker-compose of OIDC setup for IMAP, SMTP and JMAP in
>> https://github.com/apache/james-project/tree/master/examples/oidc. This
>> would include: - A LDAP still used by James UsersRepository. Provisioned
>> with a testing user. - A pre-configured Keycloack [2] OpenID connect
>> provider. - A pre-configured Krakend API gateway proxying JMAP - And
>> finally a James server configured to only accept OIDC as an
>> authentication mechanism for IMAP, SMTP and JMAP. - Unit tests for
>> existing IMAP `plainAuthDissallowed` configuration parameter. Finally
>> this is a good opportunity to restructure authentication related
>> settings in imapserver.xml and smtpserver.xml file. Here are proposals
>> for both files: [imapserver.xml] ---- <imapserver enabled="true">
>> <jmxName>imapserver-ssl</jmxName> <bind>0.0.0.0:993</bind> <tls
>> socketTLS="true" startTLS="false">
>> <privateKey>file://conf/private.key</privateKey>
>> <certificates>file://conf/certs.self-signed.csr</certificates> </tls>
>> <!-- ... --> <authentication>
>> <plainAuthEnabled>true|false</plainAuthEnabled> <!-- defaults to true
>> --> <oauth> <!-- ommiting this block would disable oauth. All fields are
>> compulsory --> <publicKey>file://conf/imapJWT.pub</publicKey>
>> <oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
>> <claim>mailAddress</claim> </oauth> </authentication> </imapserver> ----
>> [smtpserver.xml] ---- <smtpserver enabled="true">
>> <jmxName>smtpserver-ssl</jmxName> <bind>0.0.0.0:465</bind> <tls
>> socketTLS="true" startTLS="false">
>> <privateKey>file://conf/private.key</privateKey>
>> <certificates>file://conf/certs.self-signed.csr</certificates> </tls>
>> <!--- ... --> <requireAuthForRelay>true|false</requireAuthForRelay>
>> <authentication> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
>> defaults to true --> <oauth> <!-- ommiting this block would disable
>> oauth. All fields are compulsory -->
>> <publicKey>file://conf/imapJWT.pub</publicKey>
>> <oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
>> <claim>mailAddress</claim> </oauth> </authentication> </smtpserver> ----
>> You can see that: - The `plainAuthDissallowed` parameter is proposed to
>> be renamed to `auth.requireSSL`. (of course we should support fallback
>> NOT to have a breaking change) - `auth.plainAuthEnabled` enable turning
>> on/off plain auth, which allows having OIDC only mechanism. -
>> `auth.requireSSL` will be generalized to SMTP. - In SMTP `requireAuth`
>> setting is very misleading as it rather is `requireAuthForRelay`. I
>> propose we rename this configuration option (of course we should support
>> fallback NOT to have a breaking change). Here is the implementation
>> strategies we would follow: - For JMAP have Krakend doing all the hard
>> job for us, and use a dedicated header to carry the information over to
>> James. - Our code contributions aims at easing such a setup (that would
>> only require configuration) - Provide an informative example using
>> krakend. We understand that this choice is ours, yet sharing it could
>> allow reuse or similar setup - If some people wishes to write an OIDC
>> authentication strategy directly in James then they perfectly can!
>> (Reusing the modularization of JMAP authentication strategies we would
>> provide). - For IMAP and SMTP then we proposes to check the bearer
>> payload against a statically configured public key for these protocols.
>> (Sadly there is no API gateway for those protocols) - Drawbacks includes
>> no revocation of access tokens (once it's signed it is always valid),
>> revocation do not shut down existing connections authenticated with the
>> revocated token, and key rotation would require reconfiguration and
>> reboot. - One alternative would be to systematically ask the OpenID
>> server to validate the bearer. This might be acceptable as IMAP and SMTP
>> are long lived protocols that do not often establish new connections.
>> While this do not change anything regarding already opened connection
>> management, this solves revocation and public key rotation at the price
>> of exposing more the identity provider... - Of course James could expose
>> a back-channel for token invalidation, stored in some kind of shared
>> storage, but this complexify things a bit. - Similarily HTTP calls could
>> be made to get the JWKS key (and cache it) but this also complexify the
>> picture quite a bit... I am deeply convinced this efforts would help
>> James admins more control over exposed authentication mechanisms and
>> ultimately offer state of the art authentication options. This should
>> help James check a few more boxes in security reviews and eventually
>> ease adoption! Useful links: [0] OpenId spec:
>> https://openid.net/specs/openid-connect-core-1_0.html [1] Krakend:
>> https://www.krakend.io/ [2] Keycloack: https://www.keycloak.org/
>> [RFC-7628] SASL OATH mechanism for SMTP and IMAP:
>> https://datatracker.ietf.org/doc/html/rfc7628 Krakend configured with
>> keycloack: https://www.krakend.io/docs/authorization/keycloak/ Krakend
>> configured with token revocation:
>> https://www.krakend.io/docs/authorization/revoking-tokens/ Best regards,
>> Benoit TELLIER|
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Authentication in James: Enable/require/disable OpenID for JMAP, IMAP and SMTP
Posted by Jean Helou <je...@gmail.com>.
+1
On Thu, Dec 2, 2021 at 5:57 AM btellier@linagora.com <bt...@linagora.com>
wrote:
> Hopefully rendered correctly in plain text...
>
> -----------------------------------------
>
> Hello Jamers!
>
> As part of my work at Linagora, we are looking toward
> - better integrating James within our product suite and for us this
> means support "Single Sign On" and "Single Log Out" for JMAP following
> the OpenId connect standard [0].
> - Improving security standards used to opperate James. (We have a
> growing activity within the health care market, sensible to security
> arguments)
>
> Regarding security standards we should ideally:
> - Be able to NOT advertise AUTH / LOGIN capabilities of unencrypted
> channels (Correspond to IMAP plainAuthDissallowed but generalized to
> other protocols)
> - Be able to require OAUTH/OIDC authentication for all protocols (IMAP,
> SMTP, JMAP) - this is what some of the health care providers we spoke to
> desired to do.
> - For our collaborative suite usage, while OIDC only for JMAP makes
> sense, we still wish to maintain PLAIN AUTH for IMAP and SMTP.
> - Of course settings for regular users not interested in OIDC should
> not change (no breaking changes, OIDC adoption is opt-in only).
>
> As such we propose ourselves to:
> - Contribute IMAP and SMTP SASL OAUTH extension described in [RFC-7628]
> - Modularize JMAP authentication mechanisms (letting the admin choose
> which one she wishes to use)
> - Enable authentication through a header mechanism eg `X-USER:
> btellier@apache.org`, which can be used to delegate OIDC authentication
> through a third party API gateway. We have Krackend [1] in mind.
> - Share documentation and a docker-compose of OIDC setup for IMAP, SMTP
> and JMAP in
> https://github.com/apache/james-project/tree/master/examples/oidc. This
> would include:
> - A LDAP still used by James UsersRepository. Provisionned with a
> testing user.
> - A pre-configured Keycloack [2] OpenID connect provider.
> - A pre-configured Krakend API gateway proxying JMAP
> - And finally a James server configured to only accept OIDC as an
> authentication mechanism for IMAP, SMTP and JMAP.
> - Unit tests for existing IMAP `plainAuthDissallowed` configuration
> parameter.
>
> Finally this is a good opportunity to restructure authentication related
> settings in imapserver.xml and smtpserver.xml file.
>
> Here are proposals for both files:
>
> [imapserver.xml]
> ----
> <imapserver enabled="true">
> <jmxName>imapserver-ssl</jmxName>
> <bind>0.0.0.0:993</bind>
> <tls socketTLS="true" startTLS="false">
> <privateKey>file://conf/private.key</privateKey>
> <certificates>file://conf/certs.self-signed.csr</certificates>
> </tls>
> <!-- ... -->
> <authentication>
> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
> defaults to true -->
> <oauth> <!-- ommiting this block would disable oauth. All
> fields are compulsory -->
> <publicKey>file://conf/imapJWT.pub</publicKey>
>
> <oidcConfigurationURL>https://example.com/.well-known/openid-config
> </oidcConfigurationURL>
> <claim>mailAddress</claim>
> </oauth>
> </authentication>
> </imapserver>
> ----
>
> [smtpserver.xml]
> ----
> <smtpserver enabled="true">
> <jmxName>smtpserver-ssl</jmxName>
> <bind>0.0.0.0:465</bind>
> <tls socketTLS="true" startTLS="false">
> <privateKey>file://conf/private.key</privateKey>
> <certificates>file://conf/certs.self-signed.csr</certificates>
> </tls>
> <!--- ... -->
> <requireAuthForRelay>true|false</requireAuthForRelay>
> <authentication>
> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
> defaults to true -->
> <oauth> <!-- ommiting this block would disable oauth. All
> fields are compulsory -->
> <publicKey>file://conf/imapJWT.pub</publicKey>
>
> <oidcConfigurationURL>https://example.com/.well-known/openid-config
> </oidcConfigurationURL>
> <claim>mailAddress</claim>
> </oauth>
> </authentication>
> </smtpserver>
> ----
>
> You can see that:
> - The `plainAuthDissallowed` parameter is proposed to be renamed to
> `auth.requireSSL`. (of course we should support fallback NOT to have a
> breaking change)
> - `auth.plainAuthEnabled` enable turning on/off plain auth, which
> allows having OIDC only mechanism.
> - `auth.requireSSL` will be generalized to SMTP.
> - In SMTP `requireAuth` setting is very misleading as it rather is
> `requireAuthForRelay`. I propose we rename this configuration option (of
> course we should support fallback NOT to have a breaking change).
>
> Here is the implementation strategies we would follow:
>
> - For JMAP have Krakend doing all the hard job for us, and use a
> dedicated header to carry the information over to James.
> - Our code contributions aims at easing such a setup (that would only
> require configuration)
> - Provide an informative example using krakend. We understand that
> this choice is ours, yet sharing it could allow reuse or similar setup
> - If some people wishes to write an OIDC authentication strategy
> directly in James then they perfectly can! (Reusing the modularization
> of JMAP authentication strategies we would provide).
>
> - For IMAP and SMTP then we proposes to check the bearer payload
> against a statically configured public key for these protocols. (Sadly
> there is no API gateway for those protocols)
> - Drawbacks includes no revocation of access tokens (once it's signed
> it is always valid), revocation do not shut down existing connections
> authenticated with the revocated token, and key rotation would require
> reconfiguration and reboot.
> - One alternative would be to systematically ask the OpenID server to
> validate the bearer. This might be acceptable as IMAP and SMTP are long
> lived protocols that do not often establish new connections. While this
> do not change anything regarding already opened connection management,
> this solves revocation and public key rotation at the price of exposing
> more the identity provider...
> - Of course James could expose a back-channel for token invalidation,
> stored in some kind of shared storage, but this complexify things a bit.
> - Similarily HTTP calls could be made to get the JWKS key (and cache
> it) but this also complexify the picture quite a bit...
>
> I am deeply convinced this efforts would help James admins more control
> over exposed authentication mechanisms and ultimately offer state of the
> art authentication options. This should help James check a few more
> boxes in security reviews and eventually ease adoption!
>
> Useful links:
>
> [0] OpenId spec: https://openid.net/specs/openid-connect-core-1_0.html
>
>
> [1] Krakend: https://www.krakend.io/
> [2] Keycloack: https://www.keycloak.org/
> [RFC-7628] SASL OATH mechanism for SMTP and IMAP:
> https://datatracker.ietf.org/doc/html/rfc7628
> Krakend configured with keycloack:
> https://www.krakend.io/docs/authorization/keycloak/
> Krakend configured with token revocation:
> https://www.krakend.io/docs/authorization/revoking-tokens/
>
> Best regards,
>
> Benoit TELLIER
>
> On 02/12/2021 11:41, btellier@apache.org wrote:
> > |Hello Jamers! As part of our work at Linagora, we are looking toward -
> > better integrating James within our product suite and for us this means
> > support "Single Sign On" and "Single Log Out" for JMAP following the
> > OpenId connect standard [0]. - Improving security standards used to
> > operate James. (We have a growing activity within the health care
> > market, sensible to security arguments) Regarding security standards we
> > should ideally: - Be able to NOT advertise AUTH / LOGIN capabilities of
> > unencrypted channels (Correspond to IMAP plainAuthDissallowed but
> > generalized to other protocols) - Be able to require OAUTH/OIDC
> > authentication for all protocols (IMAP, SMTP, JMAP) - this is what some
> > of the health care providers we spoke to desired to do. - For our
> > collaborative suite usage, while OIDC only for JMAP makes sense, we
> > still wish to maintain PLAIN AUTH for IMAP and SMTP. - Of course
> > settings for regular users not interested in OIDC should not change (no
> > breaking changes, OIDC adoption is opt-in only). As such we propose
> > ourselves to: - Contribute IMAP and SMTP SASL OAUTH extension described
> > in [RFC-7628] - Modularize JMAP authentication mechanisms (letting the
> > admin choose which one she wishes to use) - Enable authentication
> > through a header mechanism eg `X-USER: btellier@apache.org`, which can
> > be used to delegate OIDC authentication through a third party API
> > gateway. We have Krackend [1] in mind. - Share documentation and a
> > docker-compose of OIDC setup for IMAP, SMTP and JMAP in
> > https://github.com/apache/james-project/tree/master/examples/oidc. This
> > would include: - A LDAP still used by James UsersRepository. Provisioned
> > with a testing user. - A pre-configured Keycloack [2] OpenID connect
> > provider. - A pre-configured Krakend API gateway proxying JMAP - And
> > finally a James server configured to only accept OIDC as an
> > authentication mechanism for IMAP, SMTP and JMAP. - Unit tests for
> > existing IMAP `plainAuthDissallowed` configuration parameter. Finally
> > this is a good opportunity to restructure authentication related
> > settings in imapserver.xml and smtpserver.xml file. Here are proposals
> > for both files: [imapserver.xml] ---- <imapserver enabled="true">
> > <jmxName>imapserver-ssl</jmxName> <bind>0.0.0.0:993</bind> <tls
> > socketTLS="true" startTLS="false">
> > <privateKey>file://conf/private.key</privateKey>
> > <certificates>file://conf/certs.self-signed.csr</certificates> </tls>
> > <!-- ... --> <authentication>
> > <plainAuthEnabled>true|false</plainAuthEnabled> <!-- defaults to true
> > --> <oauth> <!-- ommiting this block would disable oauth. All fields are
> > compulsory --> <publicKey>file://conf/imapJWT.pub</publicKey>
> > <oidcConfigurationURL>https://example.com/.well-known/openid-config
> </oidcConfigurationURL>
> > <claim>mailAddress</claim> </oauth> </authentication> </imapserver> ----
> > [smtpserver.xml] ---- <smtpserver enabled="true">
> > <jmxName>smtpserver-ssl</jmxName> <bind>0.0.0.0:465</bind> <tls
> > socketTLS="true" startTLS="false">
> > <privateKey>file://conf/private.key</privateKey>
> > <certificates>file://conf/certs.self-signed.csr</certificates> </tls>
> > <!--- ... --> <requireAuthForRelay>true|false</requireAuthForRelay>
> > <authentication> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
> > defaults to true --> <oauth> <!-- ommiting this block would disable
> > oauth. All fields are compulsory -->
> > <publicKey>file://conf/imapJWT.pub</publicKey>
> > <oidcConfigurationURL>https://example.com/.well-known/openid-config
> </oidcConfigurationURL>
> > <claim>mailAddress</claim> </oauth> </authentication> </smtpserver> ----
> > You can see that: - The `plainAuthDissallowed` parameter is proposed to
> > be renamed to `auth.requireSSL`. (of course we should support fallback
> > NOT to have a breaking change) - `auth.plainAuthEnabled` enable turning
> > on/off plain auth, which allows having OIDC only mechanism. -
> > `auth.requireSSL` will be generalized to SMTP. - In SMTP `requireAuth`
> > setting is very misleading as it rather is `requireAuthForRelay`. I
> > propose we rename this configuration option (of course we should support
> > fallback NOT to have a breaking change). Here is the implementation
> > strategies we would follow: - For JMAP have Krakend doing all the hard
> > job for us, and use a dedicated header to carry the information over to
> > James. - Our code contributions aims at easing such a setup (that would
> > only require configuration) - Provide an informative example using
> > krakend. We understand that this choice is ours, yet sharing it could
> > allow reuse or similar setup - If some people wishes to write an OIDC
> > authentication strategy directly in James then they perfectly can!
> > (Reusing the modularization of JMAP authentication strategies we would
> > provide). - For IMAP and SMTP then we proposes to check the bearer
> > payload against a statically configured public key for these protocols.
> > (Sadly there is no API gateway for those protocols) - Drawbacks includes
> > no revocation of access tokens (once it's signed it is always valid),
> > revocation do not shut down existing connections authenticated with the
> > revocated token, and key rotation would require reconfiguration and
> > reboot. - One alternative would be to systematically ask the OpenID
> > server to validate the bearer. This might be acceptable as IMAP and SMTP
> > are long lived protocols that do not often establish new connections.
> > While this do not change anything regarding already opened connection
> > management, this solves revocation and public key rotation at the price
> > of exposing more the identity provider... - Of course James could expose
> > a back-channel for token invalidation, stored in some kind of shared
> > storage, but this complexify things a bit. - Similarily HTTP calls could
> > be made to get the JWKS key (and cache it) but this also complexify the
> > picture quite a bit... I am deeply convinced this efforts would help
> > James admins more control over exposed authentication mechanisms and
> > ultimately offer state of the art authentication options. This should
> > help James check a few more boxes in security reviews and eventually
> > ease adoption! Useful links: [0] OpenId spec:
> > https://openid.net/specs/openid-connect-core-1_0.html [1] Krakend:
> > https://www.krakend.io/ [2] Keycloack: https://www.keycloak.org/
> > [RFC-7628] SASL OATH mechanism for SMTP and IMAP:
> > https://datatracker.ietf.org/doc/html/rfc7628 Krakend configured with
> > keycloack: https://www.krakend.io/docs/authorization/keycloak/ Krakend
> > configured with token revocation:
> > https://www.krakend.io/docs/authorization/revoking-tokens/ Best regards,
> > Benoit TELLIER|
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
Re: Authentication in James: Enable/require/disable OpenID for JMAP, IMAP and SMTP
Posted by "btellier@linagora.com" <bt...@linagora.com>.
Hopefully rendered correctly in plain text...
-----------------------------------------
Hello Jamers!
As part of my work at Linagora, we are looking toward
- better integrating James within our product suite and for us this
means support "Single Sign On" and "Single Log Out" for JMAP following
the OpenId connect standard [0].
- Improving security standards used to opperate James. (We have a
growing activity within the health care market, sensible to security
arguments)
Regarding security standards we should ideally:
- Be able to NOT advertise AUTH / LOGIN capabilities of unencrypted
channels (Correspond to IMAP plainAuthDissallowed but generalized to
other protocols)
- Be able to require OAUTH/OIDC authentication for all protocols (IMAP,
SMTP, JMAP) - this is what some of the health care providers we spoke to
desired to do.
- For our collaborative suite usage, while OIDC only for JMAP makes
sense, we still wish to maintain PLAIN AUTH for IMAP and SMTP.
- Of course settings for regular users not interested in OIDC should
not change (no breaking changes, OIDC adoption is opt-in only).
As such we propose ourselves to:
- Contribute IMAP and SMTP SASL OAUTH extension described in [RFC-7628]
- Modularize JMAP authentication mechanisms (letting the admin choose
which one she wishes to use)
- Enable authentication through a header mechanism eg `X-USER:
btellier@apache.org`, which can be used to delegate OIDC authentication
through a third party API gateway. We have Krackend [1] in mind.
- Share documentation and a docker-compose of OIDC setup for IMAP, SMTP
and JMAP in
https://github.com/apache/james-project/tree/master/examples/oidc. This
would include:
- A LDAP still used by James UsersRepository. Provisionned with a
testing user.
- A pre-configured Keycloack [2] OpenID connect provider.
- A pre-configured Krakend API gateway proxying JMAP
- And finally a James server configured to only accept OIDC as an
authentication mechanism for IMAP, SMTP and JMAP.
- Unit tests for existing IMAP `plainAuthDissallowed` configuration
parameter.
Finally this is a good opportunity to restructure authentication related
settings in imapserver.xml and smtpserver.xml file.
Here are proposals for both files:
[imapserver.xml]
----
<imapserver enabled="true">
<jmxName>imapserver-ssl</jmxName>
<bind>0.0.0.0:993</bind>
<tls socketTLS="true" startTLS="false">
<privateKey>file://conf/private.key</privateKey>
<certificates>file://conf/certs.self-signed.csr</certificates>
</tls>
<!-- ... -->
<authentication>
<plainAuthEnabled>true|false</plainAuthEnabled> <!--
defaults to true -->
<oauth> <!-- ommiting this block would disable oauth. All
fields are compulsory -->
<publicKey>file://conf/imapJWT.pub</publicKey>
<oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
<claim>mailAddress</claim>
</oauth>
</authentication>
</imapserver>
----
[smtpserver.xml]
----
<smtpserver enabled="true">
<jmxName>smtpserver-ssl</jmxName>
<bind>0.0.0.0:465</bind>
<tls socketTLS="true" startTLS="false">
<privateKey>file://conf/private.key</privateKey>
<certificates>file://conf/certs.self-signed.csr</certificates>
</tls>
<!--- ... -->
<requireAuthForRelay>true|false</requireAuthForRelay>
<authentication>
<plainAuthEnabled>true|false</plainAuthEnabled> <!--
defaults to true -->
<oauth> <!-- ommiting this block would disable oauth. All
fields are compulsory -->
<publicKey>file://conf/imapJWT.pub</publicKey>
<oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
<claim>mailAddress</claim>
</oauth>
</authentication>
</smtpserver>
----
You can see that:
- The `plainAuthDissallowed` parameter is proposed to be renamed to
`auth.requireSSL`. (of course we should support fallback NOT to have a
breaking change)
- `auth.plainAuthEnabled` enable turning on/off plain auth, which
allows having OIDC only mechanism.
- `auth.requireSSL` will be generalized to SMTP.
- In SMTP `requireAuth` setting is very misleading as it rather is
`requireAuthForRelay`. I propose we rename this configuration option (of
course we should support fallback NOT to have a breaking change).
Here is the implementation strategies we would follow:
- For JMAP have Krakend doing all the hard job for us, and use a
dedicated header to carry the information over to James.
- Our code contributions aims at easing such a setup (that would only
require configuration)
- Provide an informative example using krakend. We understand that
this choice is ours, yet sharing it could allow reuse or similar setup
- If some people wishes to write an OIDC authentication strategy
directly in James then they perfectly can! (Reusing the modularization
of JMAP authentication strategies we would provide).
- For IMAP and SMTP then we proposes to check the bearer payload
against a statically configured public key for these protocols. (Sadly
there is no API gateway for those protocols)
- Drawbacks includes no revocation of access tokens (once it's signed
it is always valid), revocation do not shut down existing connections
authenticated with the revocated token, and key rotation would require
reconfiguration and reboot.
- One alternative would be to systematically ask the OpenID server to
validate the bearer. This might be acceptable as IMAP and SMTP are long
lived protocols that do not often establish new connections. While this
do not change anything regarding already opened connection management,
this solves revocation and public key rotation at the price of exposing
more the identity provider...
- Of course James could expose a back-channel for token invalidation,
stored in some kind of shared storage, but this complexify things a bit.
- Similarily HTTP calls could be made to get the JWKS key (and cache
it) but this also complexify the picture quite a bit...
I am deeply convinced this efforts would help James admins more control
over exposed authentication mechanisms and ultimately offer state of the
art authentication options. This should help James check a few more
boxes in security reviews and eventually ease adoption!
Useful links:
[0] OpenId spec: https://openid.net/specs/openid-connect-core-1_0.html
[1] Krakend: https://www.krakend.io/
[2] Keycloack: https://www.keycloak.org/
[RFC-7628] SASL OATH mechanism for SMTP and IMAP:
https://datatracker.ietf.org/doc/html/rfc7628
Krakend configured with keycloack:
https://www.krakend.io/docs/authorization/keycloak/
Krakend configured with token revocation:
https://www.krakend.io/docs/authorization/revoking-tokens/
Best regards,
Benoit TELLIER
On 02/12/2021 11:41, btellier@apache.org wrote:
> |Hello Jamers! As part of our work at Linagora, we are looking toward -
> better integrating James within our product suite and for us this means
> support "Single Sign On" and "Single Log Out" for JMAP following the
> OpenId connect standard [0]. - Improving security standards used to
> operate James. (We have a growing activity within the health care
> market, sensible to security arguments) Regarding security standards we
> should ideally: - Be able to NOT advertise AUTH / LOGIN capabilities of
> unencrypted channels (Correspond to IMAP plainAuthDissallowed but
> generalized to other protocols) - Be able to require OAUTH/OIDC
> authentication for all protocols (IMAP, SMTP, JMAP) - this is what some
> of the health care providers we spoke to desired to do. - For our
> collaborative suite usage, while OIDC only for JMAP makes sense, we
> still wish to maintain PLAIN AUTH for IMAP and SMTP. - Of course
> settings for regular users not interested in OIDC should not change (no
> breaking changes, OIDC adoption is opt-in only). As such we propose
> ourselves to: - Contribute IMAP and SMTP SASL OAUTH extension described
> in [RFC-7628] - Modularize JMAP authentication mechanisms (letting the
> admin choose which one she wishes to use) - Enable authentication
> through a header mechanism eg `X-USER: btellier@apache.org`, which can
> be used to delegate OIDC authentication through a third party API
> gateway. We have Krackend [1] in mind. - Share documentation and a
> docker-compose of OIDC setup for IMAP, SMTP and JMAP in
> https://github.com/apache/james-project/tree/master/examples/oidc. This
> would include: - A LDAP still used by James UsersRepository. Provisioned
> with a testing user. - A pre-configured Keycloack [2] OpenID connect
> provider. - A pre-configured Krakend API gateway proxying JMAP - And
> finally a James server configured to only accept OIDC as an
> authentication mechanism for IMAP, SMTP and JMAP. - Unit tests for
> existing IMAP `plainAuthDissallowed` configuration parameter. Finally
> this is a good opportunity to restructure authentication related
> settings in imapserver.xml and smtpserver.xml file. Here are proposals
> for both files: [imapserver.xml] ---- <imapserver enabled="true">
> <jmxName>imapserver-ssl</jmxName> <bind>0.0.0.0:993</bind> <tls
> socketTLS="true" startTLS="false">
> <privateKey>file://conf/private.key</privateKey>
> <certificates>file://conf/certs.self-signed.csr</certificates> </tls>
> <!-- ... --> <authentication>
> <plainAuthEnabled>true|false</plainAuthEnabled> <!-- defaults to true
> --> <oauth> <!-- ommiting this block would disable oauth. All fields are
> compulsory --> <publicKey>file://conf/imapJWT.pub</publicKey>
> <oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
> <claim>mailAddress</claim> </oauth> </authentication> </imapserver> ----
> [smtpserver.xml] ---- <smtpserver enabled="true">
> <jmxName>smtpserver-ssl</jmxName> <bind>0.0.0.0:465</bind> <tls
> socketTLS="true" startTLS="false">
> <privateKey>file://conf/private.key</privateKey>
> <certificates>file://conf/certs.self-signed.csr</certificates> </tls>
> <!--- ... --> <requireAuthForRelay>true|false</requireAuthForRelay>
> <authentication> <plainAuthEnabled>true|false</plainAuthEnabled> <!--
> defaults to true --> <oauth> <!-- ommiting this block would disable
> oauth. All fields are compulsory -->
> <publicKey>file://conf/imapJWT.pub</publicKey>
> <oidcConfigurationURL>https://example.com/.well-known/openid-config</oidcConfigurationURL>
> <claim>mailAddress</claim> </oauth> </authentication> </smtpserver> ----
> You can see that: - The `plainAuthDissallowed` parameter is proposed to
> be renamed to `auth.requireSSL`. (of course we should support fallback
> NOT to have a breaking change) - `auth.plainAuthEnabled` enable turning
> on/off plain auth, which allows having OIDC only mechanism. -
> `auth.requireSSL` will be generalized to SMTP. - In SMTP `requireAuth`
> setting is very misleading as it rather is `requireAuthForRelay`. I
> propose we rename this configuration option (of course we should support
> fallback NOT to have a breaking change). Here is the implementation
> strategies we would follow: - For JMAP have Krakend doing all the hard
> job for us, and use a dedicated header to carry the information over to
> James. - Our code contributions aims at easing such a setup (that would
> only require configuration) - Provide an informative example using
> krakend. We understand that this choice is ours, yet sharing it could
> allow reuse or similar setup - If some people wishes to write an OIDC
> authentication strategy directly in James then they perfectly can!
> (Reusing the modularization of JMAP authentication strategies we would
> provide). - For IMAP and SMTP then we proposes to check the bearer
> payload against a statically configured public key for these protocols.
> (Sadly there is no API gateway for those protocols) - Drawbacks includes
> no revocation of access tokens (once it's signed it is always valid),
> revocation do not shut down existing connections authenticated with the
> revocated token, and key rotation would require reconfiguration and
> reboot. - One alternative would be to systematically ask the OpenID
> server to validate the bearer. This might be acceptable as IMAP and SMTP
> are long lived protocols that do not often establish new connections.
> While this do not change anything regarding already opened connection
> management, this solves revocation and public key rotation at the price
> of exposing more the identity provider... - Of course James could expose
> a back-channel for token invalidation, stored in some kind of shared
> storage, but this complexify things a bit. - Similarily HTTP calls could
> be made to get the JWKS key (and cache it) but this also complexify the
> picture quite a bit... I am deeply convinced this efforts would help
> James admins more control over exposed authentication mechanisms and
> ultimately offer state of the art authentication options. This should
> help James check a few more boxes in security reviews and eventually
> ease adoption! Useful links: [0] OpenId spec:
> https://openid.net/specs/openid-connect-core-1_0.html [1] Krakend:
> https://www.krakend.io/ [2] Keycloack: https://www.keycloak.org/
> [RFC-7628] SASL OATH mechanism for SMTP and IMAP:
> https://datatracker.ietf.org/doc/html/rfc7628 Krakend configured with
> keycloack: https://www.krakend.io/docs/authorization/keycloak/ Krakend
> configured with token revocation:
> https://www.krakend.io/docs/authorization/revoking-tokens/ Best regards,
> Benoit TELLIER|
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org