Table of contents
Blog post by: Robert Sturim, TraceLink Chief Technology Officer
In my last blog post, Ownership, I discussed the concept of application owners on the TraceLink platform. This week I want to extend the discussion to include partners and process networks and discuss how those concepts drive data access control.
Last week, I described Application Owners. All applications on the TraceLink platform have a clear owner – the company that licenses the application and therefore owns the data stored within that application. Some applications, such as APT, are licensed to TraceLink customers. Other applications – System Applications, such as the workflow manager or the metadata manager – are owned by the Prometheus company.
Applications that are licensed to TraceLink customers are either Enterprise Applications or Multi-Enterprise Applications. The licensee of such an application is the Application Owner. Application owners always have access to the data stored in that application. Additionally, for Enterprise/Multi-Enterprise applications, the application owner establishes links to other companies and locations. Once linked, those companies and locations are known as partners in the context of that application.
In a multi-enterprise application, the application owner can link to any company or location on the TraceLink network. In some cases, partners can include the locations of the application owner. Consider for example a pharmaceutical company, Bob’s Super Drug (BSD). This company has two different products – Super Smart Brain Pills are manufactured at BSD Boston – a plant owned and operated by Bob’s Super Drug. For the other product line Super Sleep Aid, BSD had contracted with a contract manufacturer (or CMO), Pills-R-Us. BSD licenses TraceLink’s Serial Number Exchange (SNX) application. Its network might look as follows:
In the context of BSD’s SNX application, BSD has created two links – one to its own BSD Boston Location, and one to the Pills-R-Us company.
Enterprise applications are similar to multi-enterprise applications with one caveat – in enterprise applications, the application owner only links to locations owned by the application owner. An enterprise application cannot link to 3rd party companies or locations.
Membership
A user can be a member of an application. Users are members of an application in the context of a network node. This is a key concept. A user can be a member of the application at the owning company, in which case the user is said to be a member as an application owner. A user can be a member of an application at one or more partner companies and locations, in which case the user is said to be a member as a partner.
Data in an enterprise or multi-enterprise application is often associated with a partner. In our example above, SNX is used by production lines to request serial numbers that can be placed onto packages (e.g., bottles) as they are manufactured. For SNX requests sent by BSD Boston, those requests are associated with the BSD Boston partner, and likewise, requests sent by Pills-R-Us are associated with the Pills-R-Us partner.
Users who are members as application owners have access to data across all partners. In our example above, a user who is a member at BSD can see all SNX requests, including those sent by BSD Boston as well as those sent by Pills-R-Us.
Users who are not members as an owner, but are a member at a partner, can only see those transactions associated with that partner. In our example above a user who is a member of BSD Boston can only see requests sent by BSD Boston. They cannot see those requests sent by Pills-R-Us. Note that this user may indeed be an employee of BSD, but since they are not a member at the owning network node, that user can only see a subset of the data.
Users can have multiple memberships in an application. It is possible that the same user could be a member as an owner and as a partner. In this case, the fact the user is a member as an owner entitles that user to see data across all partners. Users who are not an owner but have multiple partner memberships can see the data associated with each of those partners.
In the LSC platform, application membership was limited to company members. That is to say, a user could only be a member of an application as an owner if that user was a member of the company that owned the application. And, a user could only be a member as a partner if that user was a member of the partner company or a member of the company that owned the partner location.
In OPUS, we made a deliberate decision to remove this constraint. Any user can be made a member of an application or a process network as the owner or as a partner regardless of the company to which that user is associated. This better supports a number of use cases. For example, the user could be a contractor and consultant, employed by a third party but still doing work for the owner or partner. It also allows companies to make TraceLink support users members of their applications and process networks.
On the OPUS platform, company membership has (almost) no bearing on determining what a user is allowed to see or do. In (almost) all cases, a user's access is based upon application or process network membership, not company membership.
Please take a moment to reread that prior paragraph and make sure you understand it. I cannot stress this concept strongly enough. If you are basing any application or process network authorization logic on a user's membership in a company, you are almost certainly doing it wrong.
System applications do not typically have members. The standard pattern is for system applications to delegate questions regarding user authorization to an enterprise application.
Thus far I’ve mentioned enterprise applications, multi-enterprise applications, and system applications. For completeness, there is a fourth type of application in OPUS – a user application. Like system apps, user apps are owned by Prometheus, and users are not members of user applications. Unlike system applications, users can interact directly with user applications without proxying those calls (and authorization logic) through an enterprise application. The main criterion for an application to be a user application is that data access is based solely on the identity of the user.
A good example of a user application is the message center. Companies do not need to license the message center. Users do not need to be made a member of the message center application. The message a user is allowed to see in the message center is based solely on that user’s identity. That is to say, a user is allowed to see messages addressed to that user, and no other messages.
Process Networks
OPUS introduced the concept of process networks. Process Networks allow application owners to create multiple networks of users and partners in the context of an application. Agile Process Networks (APT) is the first application to take full advantage of process networks. The application owner may choose to create different process networks for different product lines, especially if the employees who manage those products or the partners who support those products are distinct. Or, the application owner may choose to create different process networks for different APT processes.
Many of the same concepts that I described in the previous sections apply to process networks. Process networks are owned by the application owner. A company or location can be made a partner of a process network. Partners of a process network can also include locations of the application owner. Users are members of a process network in the context of a network node, and a user’s access to that data in a process network is determined by whether that membership is at the owning company or a partner network node.
The NAA application which manages network objects has additional data structures for managing process networks, process network partners, and process network members, that are similar to applications, application partners, and application memberships. When a partner is made a partner of a process network, OPUS will automatically make that user a member of the application as well if they are not already one. And, when a user is made a member of a process network at a network node, OPUS will automatically make that user a member of that network node at the application level as well if they are not already one. Thus the application partners and memberships are essentially a union of process network partners and process network members.
Older applications, such as those that currently reside in the LSC, do not support process networks. Applications such as SOM, SNX, SNM, and Product Track only support application membership and partnership within Network Objects. In the OPUS user experience, we present a unified network paradigm to our users. By selecting a network from the network dropdown, the user is choosing the context in which they wish to operate. For applications such as APT, the user is typically selecting a process network. For applications such as SOM, SNX, SNM, and Product, we present such applications as having a single network. The user experience insulates the user from these details.
You may have heard the concept of a virtual process network. This is an approach we leveraged to support the network paradigm in the user experience, and allows the front end to treat applications as though they were process networks in the case of applications that do not directly support process networks.
WorldView
WorldView enforces data access control. WorldView reads the user’s authorization token to determine whether a user is a member of an application or process network, and restricts a user’s access to the data accordingly.
Developers are able to enable/disable the logic relating to automatic enforcement of access control based upon partner links by turning link access control on or off. This feature exists for system applications and user applications. Such applications do not support partner links, and in that context, such logic does not make sense. Enterprise Applications and Multi-Enterprise Applications should always enable the linking access control unless there is a specific and deliberate reason for disabling it. Having this feature enabled should make application development easier. More importantly, having this feature enabled removes the possibility of a coding error allowing data to be leaked to partners who should not have access to it.
