Separation of SMP api path

[iansmirlis]

Hello

I would love to separate the UI and the modification API from the basic SMP rest api which should be publicly available.

Ideally, I would like to expose only the SMP api behind an apache http/80 reverse proxy, and everything else allowed only through https and accessed only by specific IPs.

It's our common practice to minimize the exposed surface to the public internet as much as possible.

In https://github.com/phax/phoss-smp/wiki/Security is not quite obvious what is the minimum required to be publicly available.

Moreover in order to achieve this, it seems that I would have to create a bit complicated proxy configuration that it's prone to future changes or unintended exposure if the paths are changed in the future.

In a perfect world, I would like to have the option to have all the SMP read only access under a separate path instead of root. This arrangement would make my proxy security configuration much easier to enforce https and other security rules in everything else that may not need to be publicly available.

Could you advise if there's a way to configure the SMP API in this manner, or if there are any existing options or workarounds that we might consider?
Thanks

[phax]

So I converted it to a discussion.

The main problem with the Peppol SMP API atm is, that it requires API queries starting from the root path as in http://smp.helger.com/iso6523-actorid-upis%3A%3A9915%3Ahelger/ - therefore whitelisting is difficult.

Imho not exposing the following elements to the Internet should do the trick:

• Any other HTTP method then GET should be forbidden
• Block access to /secure/* from the outside

And consider the configuration properties mentioned on https://github.com/phax/phoss-smp/wiki/Security

P.S. Future versions of the SMP have a fixed query path prefix that can be used to whitelist public get access

[iansmirlis]

Thanks for your prompt reply and your insight.

Any other HTTP method then GET should be forbidden
Block access to /secure/* from the outside

The thing is that this solves only part of the issue.

Since it's a senstive project, imho the ideal security principles would be the following 2:

• Minimize Public Exposure: Do not expose more pages than it's absolutely required
  It's not only about exposing sensitive data, but also about not revealing information about what is running on the server, which versions etc. Moreover minimizing the public surface, also lowers the probability of vulnerability exploitation. (For example accessing some innocent page may result in writing to logs, combine with some log4j vulnerability -> tears)

• Mandatory Encryption for Sensitive Data: Traffic containing sensitive data (i.e. passwords) must be enforced to be encrypted
  There should be no way for the system to accept unencrypted sensitive data for obvious reasons. Allowing users to login via http://smp.helger.com instead of https://smp.helger.com is a no-no

Having this in mind, an ideal setup would be

http://smp.helger.com/ -> apache/http -> public smp-server accessible by APs for discovery
https://private.helger.com/ -> apache/https -> smp-server/public       accessible by administration infrastructure 
			                      -> smp-server/write api                     -/-

The above setup would be straightforward to setup in apache, if I had the option to create the /smp and /smp-api paths

It's not completely impossible to setup this now, but it's a bit painful and error-prone.

[phax]

I don't think it is too sensitive, as it does not deal with private data but "only" with technical routing data. Even a Business Card should not contain private data.

An alternative setup might be to run 2 different instances of phoss SMP (does not work with the XML backend).

• Instance A is acccessible through the Internet and serves all the public data queries. You might even limit access to GET queries starting with /iso6523-actorid-upis::* (don't forget to URL escape eventually). The writable REST API is disabled, all public information is hidden.
• Instance B is only accessible within your Intranet and provides writable access to the data source. That way all data can be secured with https etc.
• In that scenario Instance A and B only need to share a database

Regarding your setup proposal:

• Within the Tomcat you can use any context path you like - that is no problem. That's why there is the smp.publicurl configuration property with which you can control the "outside name" (see https://github.com/phax/phoss-smp/wiki/Configuration). Unfortunately the Host and X-Host headers are currently not used

[ri4a]

We run two instances like this. The "public" instance has a custom (cleaned) web.xml that only has the relevant servlets in addition to the reverse proxy only allowing GETs.

[iansmirlis]

I don't think it is too sensitive, as it does not deal with private data but "only" with technical routing data. Even a Business Card should not contain private data.

Yeah you are right. I meant critical. Please have in mind that there is a high possibility that SMP may run on the same machine with AP, thus some strict security policies may apply. In this case, I would have a hard time to explain to ISO27001 inspection why we allow http access

An alternative setup might be to run 2 different instances of phoss SMP (does not work with the XML backend).

I thought about that, though it seems a bit overkill.

Thanks a lot for your suggestions, however please have this issue in mind. I think that an optional clear-cut separation of administration from http smp requests in the future, would be a happy improvement.

Thanks

[phax]

@iansmirlis thanks for your input. Can you please elaborate on "clear-cut spearation" a bit more specific?

The general scenarios that come into my mind are

• Separate "read" from "write" and provide 2 different applications
  • This can not be implemented with the XML backend, because all data is in memory
• Make sure, that all writing activities can not be accessed from the Internet
  • Can be achieved today by
    • Disabling the public login via configuration
    • Configure the reverse proxy with https as stated above and in the Wiki
    • Make sure you assign the user roles properly
    • Use Bearer Token for the writable API access

Potential improvements: separate read API path from write API path, which again would contradict the REST paradigm.

So please don't get that the wrong way, but what can effectively be improved in your opinion?

[iansmirlis]

Potential improvements: separate read API path from write API path, which again would contradict the REST paradigm.

Yes in my opinion this would simplify the security setup and clarity by a lot.

Indeed this can be debatable from a philosophical standpoint but

• It would be optional
• The SMP request API and the modification API serve distinct purposes and are used by different entities. Thus, someone could argue that it's not even the same RESTful service. (This can be practically proven by the need of running a separate instance)

Thank you again for your openness to this discussion and for considering these suggestions.

[phax]

I create a poll out of that, to get the community opinion on that: #260

[ri4a]

Separate "read" from "write" and provide 2 different applications
This can not be implemented with the XML backend, because all data is in memory

Perhaps the XML backend could be reworked to use memcached. You can run this either locally or shared. The "write" app (still a single instance with XML on disk) CUDs the memcached, the "read" app reads from memcached instead of from memory. Just as fast and more scalable.

[ml-deb]

I read everything and some things still confused me.

If I block public access to /secure/* will it block also the api to the login or only the UI that is served on secure ?

Thanks

[ml-deb]

Also,

Could I just block everything that is not a GET on 80 and allow only internal traffic on 443 and allow all verbs ?

[phax]

'/secure/*' blocks the Administration UI - nothing else.
For the REST API you need to block by HTTP method (see the Security page in the Wiki)

So to the outside GET /* should be allowed