User management

Managing Users

This scenario assumes you are responsible for all the user management services, starting from user registration, and ending on passwords resets. Maps say that building mature services inhouse is a bad practice, so Atlas2 uses Auth0 as identity provider. It is fast and easy to use, and has a demo tier.

To configure Auth0, you have to:

• Have an Auth0 account
• Create new SPA client at Auth0. Don't forget to configure it (i.e. set allowed callback url).
• Put domain as issuer and Client ID as audience into config.json:

{
    "userProvider": {
        "type": "auth0",
        "auth0": {
          "audience" : "from_auth0__change_me_config_json",
          "issuer" : "from_auth0__change_me_config_json"
        }
    }
}

• build UI code by running webpack -p. It's important to run it after configuring config.json, because otherwise your UI code will be misconfigured.
• if deploying to Cloud Foundry, run cf push.

Auth0 Integrations

Auth0 offers a wide array of integrations with existing identity providers. Some of them are available only in paid tiers, but at least are very easy to enable.

Consuming other User Management services

If you want to have a complete control over users, and you do not want to rely on Auth0, you can use services that you manage or trust. In this scenario, Atlas2 will ask configured service whether to let the user in. Things like password reset must be managed somewhere else.

No verification

This approach is very useful for tests. It accepts all users, and ignores password. It is recommended to use emails as user names.

{
    "userProvider" : {
    "type" : "passport",
    "strategy" : "anonymous"
    }
}

Google

Anybody with google account can login to your system. Important configuration details can be retrieved from your Google Console.

{
    "userProvider" : {
    "type" : "passport",
    "strategy" : "google",
    "clientID" : "465155999503-lfdoopp43thr6q2rl2i8u0kmjst6crv3.apps.googleusercontent.com",
    "clientSecret" : "",
    "callbackURL" : "http://localhost:6001/auth/google/callback"
    }
}

LDAP

Thanks to this wonderful extension, the tool can ask an LDAP server whether the user should or should not be allowed. Each user should have the mail field. The exemplary config uses publicly accessible LDAP server, so you are free to play with it.

{
    "userProvider": {
    "type": "passport",
    "strategy": "ldap",
    "server": {
        "url": "ldap://ldap.forumsys.com:389",
        "bindDn": "cn=read-only-admin,dc=example,dc=com",
        "searchBase" : "dc=example, dc=com",
        "bindCredentials": "password",
        "searchFilter": "(uid={{username}})"
        }
    }
}