Miami offers a toolbox with tools that can be used to implement security into your application.

Identity and access management (IAM) is a framework of business processes, policies and technologies that facilitates the management of electronic or digital identities. With an IAM framework in place, information technology (IT) managers can control user access to critical information within their organizations.

The Miami framework is based on a combination of the IAM-framework and the AAA (Authentication, Authorization, Auditing) standard. AAA is a standard based framework used to identify the user (through authentication), what the user is authorized to do (through authorization) and capture the actions performed by the (identified) user while using the application (through accounting).

• Authentication: who are you?
   This component exists of the Identification and authentication of the IAM-framework.
• Authorization: what resources are you permitted to use?
• Accounting: what resources were accessed, at what time, by whom and what’s done?
   This is the management of the IAM-framework.

Authentication:

Identification

Identification occurs when a user (or any subject) claims or professes an identity. This can be accomplished with a username, a process ID, a smart card, or anything else that can uniquely identify a subject. 

The identity is mainly based on the Outsystems user.

Other (federation) constructions with an external identity are possible.
 Especially in constructions with api’s these flexible possibilities can be used to implement the identity needed for auditing. This is useful in situations where maintaining individual Outsystems users is not possible but auditing on the end-user is needed.

Authentication

Authentication is the process of proving an identity and it occurs when subjects provide appropriate credentials to prove their identity. For example, when a user provides the correct password with a username, the password proves that the user is the owner of the username. In short, the authentication provides proof of a claimed identity.

Miami supports most authentication methods, where basic authentication based on the Outsystems username/password is the most common.

Existing Forge components, for example JWT, can be used to implement authentication not included in Miami. There was no need to develop these functionalities in Miami.

Oauth-authorization based on tokens and refresh-tokens is already implemented and can be used.

Not only for Miami, but also for other (external) applications.

In this construction the Outsystems users is available for the complete organization, based on Oauth-authorization. This saves the cost of an expensive Oauth-soultion.

For authentication based on ‘AuthenticationObject’, changing the authentication method is possible by changing the definition.

Authorization:

Authorization

Once a user is identified and authenticated, they can be granted authorization based on their proven identity. It’s important to point out that you can’t have separate authorization without identification and authentication. In other words, if everyone logs on with the same account you can grant access to resources for everyone, or block access to resources for everyone. If everyone uses the same account, you can’t differentiate between users. However, when users have been authenticated with different user accounts, they can be granted access to different resources based on their identity.

Outsystems supports authorization with roles and groups.

Outsystems only has authorization of screens on development time.

In development functionality can be created based on the Outsystems roles.

 Authorization in Miami is built on top of the default Outsystems authorization.

Miami introduce authorization-objects. An authorization-object can be related to existing Outsystems-roles and are part by the Outsystems security framework.
 The authorization-object are maintained in runtime, what gives more flexibility. However, if they are not maintained, the objects are not authorized.

For every item that needs to be authorized an authorization-object can be created. In this way rest- and soap-api’s can be authorized. And if authorization of screens at runtime is needed, authorization objects can be created for these screens and the screens can be authorized at runtime.

Access Governance

Roles are used to authorize the Miami-screens.
 New users are created inactive and a usermanager-role is needed to activate the user.
 Planned: two-phase proces of adding roles & groups to a user.

Accountability

By default the standard Outsystems audit logs are used for extra audit information: https://success.outsystems.com/Documentation/11/Managing_the_Applications_Lifecycle/Monitor_and_Troubleshoot/Monitor_Usage_with_Audit_Logs.

If needed, this auditing can be switched by a site property to a separate audit-trail.

And if needed, this separate trails can be placed external where only the auditors have rights (only change the implementation of auditlog in the core-module). In that case I would prefer the usage of the standard Outsystems logging and implement an extract from these standard Outsystems logs.  
 Accountability over the use from (external-)applications is possible and can be realized with use of an external-user.

Multi-tenant:

Multi-tenancy is the capability to address the needs of modern enterprise applications as well as Software as a Service (SaaS) applications to reach out to multiple customers, while enforcing an effective isolation of data, configurations, and end-users.

This approach allows a single Application Server and Database Server to provide each customer with his own isolated set of computing resources.

From the customer point of view looks like you have your own application, when in fact there is a single application that allows for some degree of customization between each customer.

Outsystems supports multi-tenancy, but management is not delivered by Outsystems.

Miami can do the management of the tenants as in the Outsystems multi-tenancy.