Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Cadence authorization #2833

Closed
vancexu opened this issue Nov 18, 2019 · 4 comments
Closed

Proposal: Cadence authorization #2833

vancexu opened this issue Nov 18, 2019 · 4 comments

Comments

@vancexu
Copy link
Contributor

vancexu commented Nov 18, 2019

Problem

As a multi-tendency platform, Cadence wants to provide authN and authZ for domain owner to protect their workflows from being start/describe/terminate by unauthorized person/services.

Assuming authN is taken care already and all requests to Cadence server contains identity information (say this info lives in request context).
AuthZ needs to check: is actor X allow to perform action Y on resource Z.

Term Explain
actor Actor can a personnel or service. Personnel use Cadence CLI and Cadence Web to operate on Cadence; Service integrated with Cadence client to interact with Cadence server through RPC calls
action Action is one of Cadence API calls, such as StartWorkflowExecution, DescribeWorkflowExecution, TerminateWorkflowExecution ...
resource Resource is Cadence domain and/or workflowType

Proposal

Option 1

type AuthorizationParams struct {
	Actor string
	Action string
	Resource string
}

type Authority interface {
	IsAuthorized(ctx context.Context, params *AuthorizationParams) bool
}

Option 2

type Authority interface {
        // request is one of Cadence requests, such as StartWorkflowExecutionRequest
	IsAuthorized(ctx context.Context, request interface{}) bool 
}

With an Authority implementation, in frontend service each API handler can check IsAuthorized to approved or denied requests.
Option 1 is more clear than Option 2, but less flexible. Cadence-dev inclines proposal 1 but open to opinions from communities.

One possible open source implementation is to use Open Policy Agent, with which Cadence service maintainer can define policy and construct json input for eval.

@mfateev
Copy link
Contributor

mfateev commented Nov 18, 2019

Independently of the API chosen the Actor and Action is not enough to make the decision. For example source IP address and some other properties like workflow type might affect the authorization.

@mfateev
Copy link
Contributor

mfateev commented Nov 18, 2019

@vancexu
Copy link
Contributor Author

vancexu commented Nov 19, 2019

the Actor and Action is not enough to make the decision

True, the idea is to have all needed info in AuthorizationParams. This one should be more specific

type AuthorizationParams struct {
	Actor string
	Action string
	Domain string
        WorkflowType string
        // ... other properties if needed in future 
}

@vancexu
Copy link
Contributor Author

vancexu commented Nov 19, 2019

Current preference:

type AuthorizationParams struct {
	Actor string
	Action string
	DomainName string
	TaskList string
	// ... Other needed parameters can be added in future
}

type AuthorizationResult struct {
	AuthorizationDecision AuthorizationDecision
}

type AuthorizationDecision int

const (
	DecisionDeny AuthorizationDecision = iota
	DecisionAllow
	DecisionNoOpinion
)

type Authority interface {
	IsAuthorized(ctx context.Context, params *AuthorizationParams) (AuthorizationResult, error)
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants