Protect oscm-maildev access

[GoebelL]

Motivation The access protection to the mail mock is not appropriate for collaborative scenarios. Using this mock implies that also OSCM is not operated with real users. Otherwise all participants would have to expose all their OSCM communication contents including their personal data to the platform administrator, who has access to all mails including password notifications etc. This is not what the users want. The request is to develop a filter application MailLogin, that wraps around the mail mock and provides a form based login to authenticate the requesting user against the BSS Realm and filter out from the mail mock Web UI those emails that the authenticated OSCM user is not authorized to access.

Note: Please check the below acceptance criteria before

Requirement Specification

1. A User who has the organization administrator role can see all emails that match (in term of point 3) the email address of any of the users in his organization. Reason for this: Due the authentication before, the organization admin is needed to pick and forward the initial passwords of his users)

2. Users without the organization administrator role can see all emails that match the email address of the user.

3. An email M matches to a user email address, if this email address, as stored in the user's profile, is either contained in "mail to" (the recipients list) of M, or equals to "mail from" of M (the sender address), or both.

Details The current password protection for the oscm-maildev is implemented in the oscm-proxy start script. This is to be replaced with a web application (MailLogin) that provide a login screen and handles the authentication and authorization against oscm.

• The login requires user key and password (the user id isn't necessarily unique).
• A template for same login handling can be found in the approval tool (see oscm-approval repo). Consider to reuse the approval tool login implementation by refactoring it into oscm-commons.
• The user representation in OSCM that also provides the email address can be obtained via the SOAP API, in particular from VOUserDetails retrieved from the OSCM Identity Service - as already implemented in the approval tool.
• The required web application shall provide a servlet filter, an AuthorizationFilter-like framework implementation, that performs the authorization check as described in above Requirement Specification by reading the user roles from OSCM.
• The details of how to implement the mail filtering around the maildev mock still needs to be elaborated. We already have an MaildevReader, which processes the mock emails (for example for parsing the initial passwords from emails, which are issued in the test scenarios of the web service tests). Therefore I believe this shouldn't be hard to find out and does not require that much effort to implement.
• The proxy.conf for oscm-proxy /mail location rule has to be adapted to forward requests to MailLogin, the new login application
• Docker compose file needs to be adapted in order that oscm-maildev is not directly accessible.

Acceptance criteria Preparation: Having OSCM with sample data, create additional users without administrator roles in Supplier and Reseller organization.

Check:

• [ ] The mail mock post box ist not directly accessible via standard port 80/443
• [ ] Authentication is required and performed against OSCM
• [ ] Password implementation of oscm-proxy start script is removed
• [ ] The sample data supplier user, as organization administrator, can see his emails and the emails of only users in his organization
• [ ] A user without administrator role can only see his emails, no others

Additional context Consider adaptions required for web service test. To avoid, it may be helpful to add an test setup step that initially inserts the required modification to the compose file (e.g. port mapping), in order to make the mail mock directly accessible as it's now.

[GoebelL]

Hi @kowalczyka,

This is the feature request as discussed today. Let me know if you have any questions or comments.

[kowalczyka]

The only thing which I am not sure about in the issue is Web UI here. Is it considered to be separate UI which works on the top of Maildev API and existing Maildev Web UI would be not accessible anymore?

[GoebelL]

Actually the idea is not to have a second UI on top, but rather a filter application that forwards authorized requests to the existing Web UI mock up. Not sure regarding the filtering of email addresses. It might be necessary to operate the maildev as SMTP relay - see documentation -> https://github.com/maildev/maildev#usage. I guess the addresses are exposed via API in some way.

[kowalczyka]

After checking the documentation I cannot see any possibility to use existing Maildev Web Interface for filtering the emails by recipient.

One of the option to fulfill the requirements descrived would be preparing some simple Web UI which would work on the top of REST API delivered by maildev -https://github.com/maildev/maildev/blob/master/docs/rest.md

Operating the maildev as an SMTP relay requires configuring real SMTP service that will actually send the email to the recipient.