Enterprise Access Policies in Gitana 4.0 (Part 1)

Aug 5

In this article, we'll take a look at Access Policies -- a powerful, new feature in Gitana 4.0 that allows organizations to set up and guarantee compliance with complex, enterprise-wide security requirements. Access Policies build upon the existing access control facilities provided which include per-object ACLs and broader, team-based ACLs. They extend those capabilities by allowing administrators to express access rights in a broad sweeping and prescriptive manner -- one that allows for customization and rule-based configuration, defining access constraints that span your entire platform, go across projects, across users and across all of your content via centralized and managed policy control documents.

The Access Policy

An Access Policy document is a JSON document that defines one or more conditional statements. Each statement conditionally grants or revokes one or more authorities against a resource. If effect, each statement is a rule that is evaluated for the current user against the given resource and a determination is made of what authorities to bestow.

The basic structure of an Access Policy document looks like this:

{
    "title": "{title}",
    "statements": [{
        "action": "{action}",
        "roles": [],
        "conditions": [{
            "type": "{conditionType},
            "config": {
                ...
            }
        ]}
    }]
}

Access Policies can be assigned to Users, Groups and Teams. By assigning an Access Policy to a Group or a Team, all members of that group or team will receive the grants or revocations prescribed by the Access Policy. This includes sub-groups or principals members with nested memberships.

Finally, Access Policies can be assigned at multiple scopes. A platform-scoped Access Policy will be evaluated universally across all of your Gitana resources (including within Projects). Where as a project-scoped Access Policy is applicable only to the resources of a specific project.

Using scopes, you can centrally manage Access Policies that span the entire organization as well as centrally manage Access Policies that are then assigned project-by-project to fine tune access control rights within any given project. You may also wish to permit Project Administrators to have rights to further extend Access Policies within their individual projects or constrain that very ability, depending on your specific needs.

Access Policies in Practice

We've pulled together a few examples on how Access Policies are most commonly put to use across our customer base. We've also compiled a few simple examples to help demonstrate what Access Policies are all about.

Let's take a look at a few examples, starting with the simplest of cases.

Grant the Consumer Role to Everything

You can write an unconditional Access policy by simply omitting the conditions array.
This Access policy will grant the Consumer role to all resources.

{
    "title": "Consumer of all Resources",
    "statements": [{
        "action": "grant",
        "roles": ["consumer"]
    }]
}

Notes:

• If this Access Policy were assigned at the Platform scope, it would grant Consumer rights to a principal for everything on the tenant platform.
• If it were assigned to a specific Project, it would grant Consumer rights to a principal for everything within the project.

This includes the Project itself, the Stack, the Master Branch, any other Branch and all content on all Branches.

Needless to say, this kind of Access Policy isn't typically used. It's provided here as a starting point. Let's see some more!

Grant the Consumer Role to Content Nodes

We can improve on the previous example by constraining the grant to content nodes only. To do so, we can introduce a Condition. Specifically, we'll use the type condition to constrain the statement to apply only to resources of type node.

{
    "title": "Consumer of all Content Nodes",
    "statements": [{
        "action": "grant",
        "roles": ["consumer"],
        "conditions": [{
            "type": "type",
            "config": {
                "type": "node"
            }
        }]
    }]
}

Notes:

• If this Access Policy were assigned at the Platform scope, it would grant Consumer rights to a principal for all content nodes across all projects on the tenant platform.
• If it were assigned to a specific Project, it would grant Consumer rights to a principal for all content nodes within that specific project.

You can learn more about the type condition here:
https://gitana.io/documentation/gitana/4.0/engine/security/access-policies/conditions/type.html

Grant the Consumer Role to Content Nodes in specific Projects

Suppose we wanted to apply the previous example at the Platform level but have it only apply to specific projects. We can use the or condition coupled with the project condition to build out the boolean logic for the binding.

Imagine that we have two projects that host content for "level 4" vendors. The first Project might be named FedEx and the second project might be named UPS. We can constrain our Access Policy to those two projects by Title like this:

{
    "title": "Consumer of all Content Nodes for Level 4 Vendor Projects",
    "statements": [{
        "action": "grant",
        "roles": ["consumer"],
        "conditions": [{
            "type": "type",
            "config": {
                "type": "node"
            }
        }, {
            "type": "or",
            "config": {
                "conditions": [{
                    "type": "project",
                    "config": {
                        "title": "FedEx"
                    }
                }, {
                    "type": "project",
                    "config": {
                        "title": "UPS"
                    }
                }]
            }
        }]
    }]
}

Note that the conditions array elements have an implicit and amongst them.

This Access Policy would be assigned at the Platform level and would only evaluate against resources within the FedEx or UPS projects.

Since the titles of Project can potentially change, we could improve this by sle also elect to constrain by ID, like this:

{
    "title": "Consumer of all Content Nodes for Level 4 Vendor Projects",
    "statements": [{
        "action": "grant",
        "roles": ["consumer"],
        "conditions": [{
            "type": "type",
            "config": {
                "type": "node"
            }
        }, {
            "type": "or",
            "config": {
                "conditions": [{
                    "type": "project",
                    "config": {
                        "id": "db247ccd3539f5aa0ef8"
                    }
                }, {
                    "type": "project",
                    "config": {
                        "id": "ada21783fc8761831bbb"
                    }
                }]
            }
        }]
    }]
}

That's not bad. However, we can improve this even further.

Suppose we simply tagged Projects with a property called vendor_level which identified the level of subscription. Then we could just tag the UPS and FedEx projects with vendor_level set to 4.

Now our Access Policy can be simplified:

{
    "title": "Consumer of all Content Nodes for Level 4 Vendor Projects",
    "statements": [{
        "action": "grant",
        "roles": ["consumer"],
        "conditions": [{
            "type": "type",
            "config": {
                "type": "node"
            }
        }, {
            "type": "project",
            "config": {
                "property": "vendor_level",
                "value": 4
            }
        }]
    }]
}

Much better! This Access Policy will automatically be applied to any Projects with the designated vendor_level. This means we can add, remove and update Projects as we wish and the Access Policy system will dynamically apply our provisioned access rights as we go!

It's also worth noting that any and all conditional rules will perform Regular Expression matching whenever textual content is being compared. In the examples above, we used simple text matches. But we could also imagine a more contrived example where we might want this Access Policy to apply to all Projects that start with the letter A. You could adjust the Condition like this:

{
    "type": "project",
    "config": {
        "title": "^A.*"
    }
}

That's it.

You can use RegEx expressions anyplace where text conditions are concerned. Use them for multi-value matches, prefix or suffix matches, partial matches and much more!

You can learn more about the project condition here:
https://gitana.io/documentation/gitana/4.0/engine/security/access-policies/conditions/project.html

You can learn more about the or condition here:
https://gitana.io/documentation/gitana/4.0/engine/security/access-policies/conditions/or.html

You can learn more about the and condition here:
https://gitana.io/documentation/gitana/4.0/engine/security/access-policies/conditions/and.html

More to Come!

In the next article, we'll continue looking at more complex and interesting examples of Access Policies. We'll take a look at revokes and ordering. And we'll cover examples that employ conditions around Branches and further Content properties including locale, path and aspect-injected, nested property paths!

Editorial Flows

Jul 20

Editorial Flows

In Gitana 4.0, we introduced a new feature called Editorial Flows. With Editorial Flows, your editorial teams launch draft workspaces where they work on content items at their own pace. They can write new content, change existing content or delete things in isolation without worrying about how it will affect the main line of content.

They are free to work without worry about stepping on each other's toes. They can make changes to the content graph, upload new files, adjust taxonomies and more! Using instant preview, they can iterate until they get everything just right. And then they can submit their changes for release using scheduled publishing!

In this article, we'll take a closer look at Editorial Flows. We'll do this by looking at how Editorial Flows bring together a number of powerful features from Gitana into a single, draft/publishinig experience. These features are:

• Branch-Based Workspaces
• Workflow
• Collaboration
• Scheduled Publishing

Let's take a look at how these work together to deliver Editoral Flows!

Branch-Based Workspaces

When you launch an Editorial Flow, Gitana automatically sets up a private workspace for you or your editorial team. This is accomplishing using the Git-like versioning system that powers Gitana. Each editorial flow gets its own Branch!

A Branch is a private workspace that forks off from the main line set of content. You can make any changes you'd like in your brranch and it won't affect users who are looking at content in the main line or in other branches! This provides complete freedom to try out new ideas, experiment, make mistakes and keep going. If you try something and it doesn't work, you can simply toss it out. But if you do produce something interesting, your contributions can be cherry picked and included in the final result.

So take chances. Your branch will track all of your changes and provide you with an instant view of everything you've done. That way, when your work is done, you have a snapshot view of all of the things you've modified -- every property, document, binary attachment and graph relationship. It's all there and instantly previewable by you, you team, your management and anyone else who needs to understand what's been worked on!

Once you're done with your work, you submit it. That's it. The editorial flow will route the work on to the next person. For example, a Manager might need to approve your changes. Or a Publishing Manager might want to merge your changes into a formal, scheduled release that will go out a week from now.

In all of those cases, your specific set of changes (i.e. the work that you've done) is perfectly captured and forwarded on within the business. It contributes, adding value to the final result.

Workflow

Each Editorial Flow is powered by the Gitana Workflow Engine -- a seamlesslly integrated, business process management engine (BPM) that powers the lifecycle of content within the platform. You can either use one of our pre-built workflow models or you can write your own to implement your exact workflow process needs. Workflow models define lifecycle transition states and they also define collaborators, event handlers, notifications, web hooks and more!

Sometimes you'll have a very simple workflow -- one where you make a change and you just expect it to get merged into the main line. If so, more power to you.

However, at other times, your workflow needs may be more advanced. They may require any editorial changes to be approved by a manager before they are merged. Or they might require scheduling of the resulting changes into a formal release that goes out at a specific time (such as Wednesday morning at 7:00am EST). Workflow models let you capture all of these requirements in a formal document that determines how the workflow executes.

As the workflow proceeds, collaborators receive emails and notifications to let them know when tasks have been assigned to them. Your editorial team simply clicks on a link to jump into Gitana. They can then make their changes and complete the work. It's as simple as that!

The Gitana Workflow engine features a large library of pre-built event handlers and an actions framework that enables your workflow to automatically send emails, fire off web hooks HTTP calls, send notifications, extract content, call out to AI services, tag your content and much more.

As workflows route through their lifecycle changes, reports are instantly generated to reveal bottlenecks and identify opportunities for process improvement. Learn where tasks are lagged or delayed. And find opportunities to improve your editoral flow time to market.

Collaboration

Each Editorial Flow that you launch can be worked on by one person or by many people all at once! You simply invite collaborators into your private workspace and then assign them to teams to grant them roles. You might choose to let some collaborators have READ ONLY rights. Whereas other collaborators might have full rights to EDIT content.

Access Policies allow you to define exactly what each user can do with each type of content in your workspace. Suppose, for example, that you wanted a collaborator to work ONLY on Spanish translations of Press Releases. Or suppose, on the other hadn, that you wanted a different collaborator to only be able to read content within the folder at the path `/customers/acme/marketing'. You can do all of this using Access Policies.

Each workspace tracks all of the changes contributed by you and anyone else you invite. In that sense, it's fair to think of workspaces as units of work. They contain within them the set of changes that the team has ultimately built and has decided to contribute back to the business.

With Editorial Flows, your editorial team can work on many different content tasks at the same time. Your team becomes aware of changes being worked on in one flow versus changes being made in another flow. They can compare these using Visual Compare. These can inspect side-by-side differences to see what document and property-level changes were made that might differ. Finally, they can Cherry Pick from the good ideas that the team has assembled, keeping the elements that yield the highest impact to the final result.

Scheduled Publishing

When an Editoral Flow completes, an agreed upon set of changes will have been produced. This set of changes might go through an approval step (depending on how the workflow is configured). But when all is said and done, the workflow completes and some final result is produced.

In some cases, this final result contain changes to content that are intended to be merged back to the main line... right away. In other cases, the goal might be to have those changes merge at some time in the future. And in still other cases, the goal might be to have those changes merge into a future release that then goes out all at once (at some time in the future).

Gitana supports all off these scenarios. Scheduled Publishing allows your changes to be targeted for a future release date. And Pull Requests make it possible for the content changes to be submitted for consideration by a Publishing Manager for a future release.

For example, you might have 3 changes that are required to go live on Friday. On Monday, you create a 3 Editorial Flows and 1 Release (scheduled for Friday). As the week progresses, you receive Pull Request notifications via email indicating that the Editorial Flows have completed and you now need to decide what to do with the results. You look at each one and you merge them into the Friday release. In this way, the Friday release builds up over time. It accumulates as your editorial teams contribute and those contributes are approved and accepted into the release.

The Gitana Publishing Engine allows you to configure fanned-out Deployment to one or more Deployment Targets. These include CDN endpoints, Amazon S3, IBM Cloud Object Storage, FTP servers, custom HTTP endpoints and even other Gitana environments running in various data centers anywhere in the world.

Upon release, your changes are deployed to to these deployment targets. Differencing allows you to inspect what is live (versus what is in your main line) to spot discrepancies. Finally, snapshots and rollback allow you to scroll your live deployment targets back or forward in time to reflect prior states of deployment in case of an error.

Summary

With Editorial Flows, Gitana 4.0 delivers an extremely powerful facility for quickly producing and publishing content to your live applications, web sites and smart API services running anywhere in the world. Reliably and On-Time. Powered by an enterprise-grade BPM workflow engine, these workflow processes deliver accountability and reportability, letting you track content contributions from inception to delivery.

Gitana 4 Roadmap – Job queue performance and management

Jul 13

With the early arrival of Gitana 4.0, we’ve improved the product to deliver a number of important improvements to our customers -- the user interface has been enhanced to provide a better editorial experience, the publishing engine now uses deltas and differencing for faster releases with smaller payloads and we’ve baked both generational and discerning AI services into the foundation of our product, just to name a few.

In this article, I’d like to provide some insight into our future direction. Specifically, I’d like to highlight our active investments into our Distributed Job Engine.

Distributed Job Engine

The Distributed Job Engine is a cluster-wide service that spawns and coordinates workers to execute long-running tasks or jobs. These are sometimes thought of as background tasks. The Job Engine is used to coordinate publishing and deployment operations, perform real-time replication, integrate with AI services, index content for full-text search, transform MIME type payloads from one format to another, extract text and metadata from files, classify and tag documents into taxonomies and more.

While the job engine is efficient and horizontally scalable in 4.0, we have identified avenues for improvement that are truly exciting. These include scheduling improvements, the introduction of fast lane assignment, dynamic reallocation, predictive routing and enhancements to reporting, events and notifications.

Scheduling

Our support for priority queues will improve to allow for a configurable, rules-based assignment resource requirements and limits for individual jobs. This will allow the scheduler to not only allocate jobs based on priority but also on required service levels and resource needs. This will empower the scheduler to allocate workers for higher priority jobs onto pods that guarantee a required service level and affinity (i.e. adequate CPU and memory to tackle the task at hand).

When all is said and done, developers will be able to launch jobs that schedule with higher or lower priority and execute within a much tighter deviation for quality of service.

Fast Lanes / Multiple Queues

Our Scheduling improvements will also include a simpler model – i.e. the notion of “fast lanes”. In effect, these are separate queues whose parameters are specified in the queue configuration itself. This frees developers from having to assign those parameter at the time that a job is submitted.

Customers will be able to separate out “fast lane” queues that automatically allocate to pods with more memory and more available resource. Some queues can be configured to take priority over others. This makes it easy for customers to monitor the quality of service of their executing jobs and make adjustments at the queue level to accommodate variations in demand.

Dynamic Reallocation

Workers that execute in the cluster can transition jobs into different states. They can even pause jobs, interrupt them or reschedule them. However, when priority work arrives, long-running and lower priority jobs sometimes need to be not only paused, but reallocated onto different pods running in the cluster.

Dynamic reallocation provides the ability for jobs to be paused, have their state passivated and then have that job remounted onto a new pod running elsewhere in the cluster. Either immediately or at a later point in time.

While this ability exists for some job types in Gitana 4.0, we will be extending it to all job types. This will support some of our improvements to priority scheduling by allowing the scheduler to query, interpret and potentially reallocate jobs that are already in-flight.

Predictive Routing

With additional metrics being gathered for jobs and executing workers, we will see increased usage of predictive artificial intelligence models to make determinations about optimal scheduling.

These models use historical information about the past performance of jobs to make future decisions on how best to allocate jobs onto worker pods. These decisions incorporate predictions about a job that take into account factors like potential execution time, memory and CPU consumption.

For jobs that execute on content in branches, these predictive services will also aid scheduling decisions that are predicated on branch locks, the number of content items being operated upon and more. These factors will play an important role in increasing parallelism and improved throughput for operations that would otherwise block based on branch-level locking.

Reporting, Events and Notifications

The additional metrics collected will be available via the API and from within the user interface. Customers will be able to inspect individual jobs (as they can now). But they’ll also be able to inspect queues to understand and validate the intended quality of service for any individual queue.

Each queue will allow for custom limits and event handlers to be configured. When an individual queue’s quality of service tests those limits, an event is raised that will trigger an event handler.

Customers can use this feature to send notifications (such as an email, Slack notification or SMS message). Or they can configure automated actions or even server-side scripted code that runs and handles the event as they best see fit.

Summary

We’re really excited at Gitana about these features. These improvements to scheduling will result in increased throughput and even better performance for our customers. We’re also excited to give our customers more control and visibility into their job executions.