Skip to content
This repository has been archived by the owner on Dec 14, 2023. It is now read-only.

Continuous Authentication Thoughts

Jump to bottom
Paul Lorenz edited this page Jul 13, 2020 · 3 revisions

There are a couple of different kinds of continuous authentication that we want to support.

SDK Driven Policy

SDKs can submit arbitrary information during authentication. This information could be used to drive policy for the duration of the API session.

Implementation

Rules Engine

One way to implement this would be via a rules engine. This would enable examples as below.

Examples

  1. SDK submits site=Chicago. This allows the identity to use an Edge Router associated with the Chicago site.
  2. SDK submits OS=Windows. This allows the identity to use a Windows specific service.
  3. SDK submits MyAppVersion=2.09. This prevents the identity from using a specific service which requires MyAppVersion > 3.05

How to translate rules into policy is also tricky. If rules changed role attributes, that could potentially be slow to process. Also, we would need to track which role attributes came from rules and which didn't so we could clean them up when rules evaluations changes. Finally, if someone were creating multiple concurrent sessions with the same identity, they could end up with inconsistent data.

However, if we creating a temporary mapping on top of the existing policy system, that could also be confusing. Filtering or mutating lists of services or edge routers would be easy to get wrong.

Temporary Role Attributes

Another way to implement this would be to allow specifying identity role attributes.

Example

The SDK could submit roleAttributes=chicago,os-windows. These would be added to the role attributes and policies would be re-evaluated. It would be difficult to do something like the MyAppVersion example above. You could have rules and policies for each version of an application, or do something like have an attribute for each major version of an application.

Performance

A primary driver here is performance. Any policy evaluation must happen before sessions can be established. This could be done by requiring evaluation to happen during authentication. Alternatively, we could mark the API session as unready until evaluation is done and either block or fail new dial/bind sessions until the evaluation is complete.

Integration

Need to figure out how SDK policies would affect

External System Integration

A Ziti admin might want to integrate with ID/Authorization/Authentication provider.

Push to Ziti

If the auth provider has a feed of events, we could use the feed to add/remove users as well as sync role attributes with some system of record. This would existing Ziti APIs and shouldn't require any additional development to support.

Time Of Use Synchronization

Ziti administrators may want to add hooks which will allow checks at specific points of use. For example, when authenticating, checking that a corresponding records exists in some external system. When using a service or edge router, checking that the pair in some external resource.

To implement this we'd like want to create some interface

type ExternalAuthenticator interface {
  CheckCreateApiSession(identity *model.Identity) error
  CheckServiceAccess(identity *model.Identity, service *model.Service) error
  CheckEdgeRouterAccess(identity *model.Identity, edgeRouter *model.EdgeRouter) error
}

We already have an AuthProcessor interface. This would need to be called in addition to that. The downside to the 'time of use' approach is that services and edge routers that an identity might not have access to would still show up in lists, but attempts to use them would fail.

Clone this wiki locally