softinstigate/restheart-security

Authorization and Authentication microservice for RESTHeart

archived

On 6/3/2020 we decided to use a mono repo to manage all restheart code. restheart-security has been merged in restheart and archived.

RESTHeart Security

restheart-security is a security microservice for RESTHeart v4, the Web API for MongoDB. It acts as a reverse proxy for HTTP resources, providing Authentication and Authorization capabilities.

restheart-security enables developers to configure security policies in standardized micro-gateway instances that are external to API and microservices implementations, avoiding coding security functions and a centralized gateway where scalability is a key concern.

restheart-security can also be used as a micro-gateway for Identity and Access Management in any HTTP-based microservices architecture.

Think about restheart-security as the "brick" that you put in front of your API and microservices to protect them.

Plugins

restheart-security is built around a pluggable architecture. It comes with a strong security implementation but you can easily extend it by implementing plugins.

Building a plugin is as easy as implementing a simple interface and edit a configuration file. Plugins also allow to quickly implement and deploy secure Web Services.

Maven artifacts

You can find pre-built Maven artifacts on Jitpack.io. That allows to add RESTHeart Security as a dependency on you own POM and build new plugins.

https://jitpack.io/#SoftInstigate/restheart-security

Documentation

Find the documentation at https://restheart.org/docs/security/overview

Setup

You need Java 11 and must download the latest release from releases page.

$ tar -xzf restheart-security-XX.tar.gz
$ cd restheart-security
$ java -jar restheart-security.jar etc/restheart-security.yml -e etc/default.properties

Building from source

You need Git, Java 11 and Maven.

$ git clone [email protected]:SoftInstigate/restheart-security.git
$ cd restheart-security
$ mvn package
$ java -jar target/restheart-security.jar etc/restheart-security.yml -e etc/default.properties

With Docker

$ docker pull softinstigate/restheart-security

Book a chat

If you have any question about RESTHeart Security and want to talk directly with the core development team, you can book a free video chat with us.

---

Made with ❤️ by SoftInstigate. Follow us on Twitter.

restheart-security's Issues

support parametric conf file

Add support of mustache parameters in uiam.yml like RESTHeart supports it in restheart.yml

Expected Behavior

When restheart admin uses mustache parameter in uiamy.yml, mustache is replaced by a value like it's done for restheart.yml (using environment variables for example)

Current Behavior

We could not use mustache parameter

Context

Our organisation prefers starting docker container with environment variable and without configuration file in file system.

Environment

n.a.

Steps to Reproduce

n.a.

Possible Implementation

Use same algorithm as used for restheart.yml

upload artifact on maven central repo

Expected Behavior

travis build process should publish the jar on maven central repo

Current Behavior

the jar is published on a private aws s3 repo

Auth-Tokens cannot be used in webapps when restheart and restheart-security are used

Expected Behavior

Responses from restheart-security should contain CORS header access-control-expose-headers including all the values Location, ETag, Auth-Token, Auth-Token-Valid-Until, Auth-Token-Location, X-Powered-By

We're interested especially in Auth-Token, Auth-Token-Valid-Until, Auth-Token-Location here.

Current Behavior

Restheart responds with access-control-expose-headers: Location, ETag, X-Powered-By. Restheart security checks that CORS headers are already present and does not alter them. Since Restheart security cares about the auth tokens and all of that, the header values access-control-expose-headers: Auth-Token, Auth-Token-Valid-Until, Auth-Token-Location are not allowed to be read by browser-side javascript.

Context

we're moving to the new restheart major release 4.0+

Environment

n/a

Steps to Reproduce

1. Use Restheart-security and restheart
2. Send Request with valid basic auth credentials to Restheart-Security
3. Observe header access-control-expose-headers.

Possible Implementation

If access-control-expose-headers is present, add relevant values instead of simply accepting what downstream restheart did.