Authentication, Authorization, Accounting/Audit (AAA)

[OwenBrotherwood]

AAA

• The concept of AAA as a middleware that ensures the correct usage of API without the model being overloaded with ACL concerns and that the middleware controls the AAA of access to an API.
• The concept of an AAA model that supports the AAA middleware ( the AAA of the AAA model is protected by the AAA middleware )
• The concept of the User model being protected by AAA middleware but not containing AAA (ACL's protection etc)
• The use of Roles, the concept of a user can be a member of a group, and the group can have a Role for which ACL's are defined.in the AAA model

Authentication

• Use of access_token in header contra url/cookie
• Exposing the information of authentication for latter use of Authorization
  • User details
  • Authentication source: local, facebook, google, LDAP etc
  • User IP: geographics
  • User memberOfGroups: local, LDAP etc

Authorization

• Usage of information from Authentication
• Time limits for authorization before a new authentication should be requested
• Roles with groups and users as member of group(s)

Accounting

• rate limiting of API usage
• "simple Accounting" payement

Audit

• What is interesting for who did what when
• a model over AAA such that the AAA can be auditet via an API and not just "read the code"

Referance

Loopback strategi

• Roadmap
• Possible main issue bearer of future loopback work for AAA

Issues of relevance

• issues/1316
• pull/1323
• issues/397
  • issues/397#issuecomment-58048529

Other "stuff"

• The whole linked account scenarios/use cases: what effects AAA<->Linked Accounts
• Keep an eye on middleware examples to ensure correct understanding loopback/issues/1352

[OwenBrotherwood]

Use Case Authorization

• User registers with email
  • The email domain is recognised, and user is placed in a group for domain (that has the lowest role)
    • The register request is forwarded to domain admin for placement in a group (that is a member of a role)
• User register with email and contract ID
  • The contract ID is recognized, and the user is placed in a group for contract id (that has the lowest role)
    • The register request is forwarded to contract admin for placement in a group (that is member of a role)

[raymondfeng]

@OwenBrotherwood Thank you for putting together the items for AAA.

@crandmck At some point, we should have a white paper for these things.

[OwenBrotherwood]

@raymondfeng
No problem: I give a +1 for #397 (comment)

[OwenBrotherwood]

Use Case Authentication

• Some external force requires 100% compliance to access_token is not a cookie or url.
  • some pull request add's an option that defines the method by which an access_token is available
• (in future version of looback) an audit shows the method by which access_token is used as this is documented by an api, or rather, the result of an api call

Issue for future Pull Request

[OwenBrotherwood]

@crandmck
http://docs.strongloop.com/display/public/LB/Security+considerations#Securityconsiderations-MitigatingXSSexploits
in relation to using headers contra other methods
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

[crandmck]

Thanks, I added that link as another reference in that section.

Re #1326, please keep me posted if any docs updates are required.

[OwenBrotherwood]

@crandmck
I will keep you posted: doc is so important to reduce support issues
I will probably do a linkedin post this weekend (eAAAs and/or eAPIs): after that I think a white paper is possible

[crandmck]

@OwenBrotherwood Thanks!

[OwenBrotherwood]

Use Case: Audit, of node modules

API that shows which node modules are used, name,version and repository, to ensure that there is no known use of depreciated modules and usage of repositories that are trusted.

Possible case for a checksum on the module.

Back to watching https://player.vimeo.com/video/77870960 then back to test (or bajtos will be after me), debug log usage and as a last resort, debugging.

[OwenBrotherwood]

Use Case: Accounting/Audit, API usage

Management or the API supplier wishes to know the value of the API in order to determince key customer and usage.

An API can expose new data to an organisation, and with Accounting/Audit, a continual Service apraisal (in the context of Service, Product, Component) can ensure that the API can be evaluated together with the users of the API.

API that shows usage of an API to address who is using the API and how much the API is used

[OwenBrotherwood]

Expand AAA to Patch and Dependancy Management

Any company wishing to enter Financial Technology has to understand
and address compliance.

A clear AAA solution is necessary but Patch and Dependancy Management is also a factor @raymondfeng

[OwenBrotherwood]

Status

@raymondfeng @altsang
In the area of Operations and Integration (in which I primarily work) the areas of AAA and Patch/Dependancy Mangement is a concern.
Any product or service requires compliance to the rules of the sector one works in. A product or service that creates too many problems in the area of security and audit is a pain in my area of work.

Strongloop should ensure that AAA and Patch/Dependancy is addressed: as a value added service.
Note: my research has not reached StrongOps yet.

Strongloop is heavily dependant on loopback.
At the present time, issue 1380 is a make or break in loopback that can allow an acceleration of getting to the market by optimising internal and community development.
#1384 is my workpad

---

Tech stack

• Integration (EIA) to "shrink wrapped" products
• Strongloop product/service
• loopback (with clear dependancy on passport)
• Node (boot) (with clear dependancy on npm)

The Node of Things (NoT) is "just" a boot for the use of Javascript from the server to the client to decrease costs for the developer: too ensure master of one programming language.
JVM and .NET are also possible as boot for the same decrease of cost.

In an enterprise, an evangulism for Javascript for server to client, without to much concentration on the M and N in MEAN, requires an understanding that going from other boot systems than node can create a better grow bed of productivity in an enterprise by decreasing startup costs and increase acceptance.
Usage of MS SQL and Java DB's allow for gradual change and, with a boot to an express server as the final step from MS or Java 'web servers' to enable Microservices