SnapLogic IPaaS introduces a robust Enterprise-grade hierarchical model to organize and provide fine-grained access control to all system assets. Assets are defined as any resource that can be created by an organization and tracked by the system in the monitoring and reporting dashboard. 

In this model there are two types of objects: Assets or Containers

SnapLogic has a completely uniform access control model based on Read, Write, and Execute permissions. All assets and containers can have an associated user and group access control list (ACL). Specific permissions can be inherited through the nested containers to simplify ACL specification. Groups of users within an organization, when combined with the new permissions model, make it easy to control how assets are used.

Customer Benefits

The assets and container hierarchy model brings immediate benefits to both enterprise customers as well as resellers. 

Enterprise Customers

For mission critical enterprise customer needs, this approach to organization and permission provides many benefits:


The most profound improvement is that enterprise customers will now see a consistent view of all of their resources associated with their account. The hierarchical organization is based on the same type of hierarchy found in commonly used file systems such as Windows, Mac OS X, and UNIX. Arbitrary folders can be created to represent an organization strategy that is appropriate for a specific customer. All SnapLogic assets live in the same namespace, which means a user cannot create the same name for different assets. For example, you cannot have a pipeline and task both called UpdateInventory in the same directory. This helps avoid confusion when naming assets.

In addition, this permissions model introduces simple Read, Write, and Execute (RWX) controls for all containers and assets. This approach, which also draws from existing file systems, lowers the conceptual weight of managing access to different assets. Any asset can be assigned zero or more permissions which form the access control list. A permission consists of a subject type, which can be a user or a group, a subject, which is a user name or a group name and, a set of permissions (RWX). In addition a permission set as inherited. This allows a user a group to be given access to everything within a folder, including everything in subfolders. This greatly simplifies the assignment of permissions to assets, especially for customers with several projects consisting of several assets.

The group feature makes it easy for customers to decouple specific users from specific permissions. This is extremely useful in situations in which a customer may have users that eventually leave their organization or their role in an organization. It is also useful for when a customer hires professional services through SnapLogic or through a third party. A group possibly combined with inheritance makes it easy to temporarily add access for a professional services consult.

By virtue of fine-grained ACL permissions at the assets and container level, the model is flexible to provide complete security isolation between folders, projects or sub-organizations for each asset type. For example, Snaps, APIs, pipelines can now be completely isolated to maintain security between different containers. On the other hand, assets can also be shared across containers, thus enabling cross-departmental and organizational collaboration.

 

Example Customer Hierarchy and Permissions 

/FooBarCorp
|  Groups:
|    [members: alice, bob, jane, john]
|    [admin: alice, bob]
|    [dev: jane]
|    [hr: john]
|-/Shared
|    ACL:
|      [dev, RWX, inherit=true]
|      [hr, X, inherit=true]
|    SalesforceAccount
|    TwitterAccount
|-/Social
|   ACL:
|     [dev, RWX, inherit=true]
|   GetTweetsPipeline
|   GetFollewrsPipeline
|   TwitterTask
|-/Reports
|   ACL:
|     [dev, RWX, inherit=true]
|     [hr, X, inherit=true]