Security

When adding security to your endpoints, there are two levels that we take into consideration: CORS for securing application access and an OAUTH implementation that uses ROLES for securing user access. Below we will go over how you can better configure these two in your implementation.

CORS / NetworkGroups

At the top of your '~/.beapi/beapi_api.yml' config file, you will see a group of lines that look like this:

apitoolkit:
    apiName: api
    attempts: 5
    procCores: 8
    networkGroups: ['private','public']
    ...

Right now we are only interested in networkGroups. The 'networkGroups' defines 'allowedOrigins' groups for CORS (Cross Origin Resource Sharing) which we can then associate with each group of endpoints in our IO state files. We associate the 'allowedOrigins' further down in the 'beapi_api.yml' file under corsInterceptor:

    corsInterceptor:
        includeEnvironments: ['development','test','production']
        excludeEnvironments: []
        networkGroups:
            public: ['http://localhost','http://localhost:8080','http://127.0.0.1','http://test.nosegrind.net']
            private: ['http://localhost','http://localhost:8080','http://127.0.0.1']
    ...

Once we have the Network groups named and defined, we can then assign them in our IO State. Below is the top of our 'Person' IO State file as an example of how we do the assignment:

{
    "NAME":"person",
    "NETWORKGRP": "public",
    "VALUES": {
        ...

You can see an example of this at the top of anyone of the pregenerated IO State files in your project.

As you can see, we use the 'public' networkGrp so it upon lookup of the endpoint, we immediately know which 'allowedOrigins' to use. Others might use 'private so that we can use INTERNAL networks rather than EXTERNAL networks. This makes it easier for us to use one backend for internal and external endpoints.

Roles / NetworkRoles

The 'networkRoles' are very similar to 'networkGroups' in that you are assigning ROLES to your 'networkGroups' as a set of ROLES to be pulled from for assignment:

apitoolkit:
    apiName: api
    attempts: 5
    procCores: 8
    networkGroups: ['private','public']
    networkRoles:
        public: ['ROLE_USER','ROLE_ADMIN']
        private: ['ROLE_ADMIN']

So above in 'public', those are the ok'd roles to use for making API calls and they will be checked against all incoming calls using 'public'

So if your IO State is declared as public, you will want your users to have ROLES listed in networkRoles.public. Pretty easy!

Single Sign-on & Providers

We are quickly trying to implement as many providers as we can into a signle sign-on for your service and if you don't see one you want, you can always donate to the project to speed up the process.

Troubleshooting