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.

Sign up for GitHub

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

[Feature/Identity] Identity use cases #5513

Merged
merged 1 commit into from
Jan 11, 2023
Merged

[Feature/Identity] Identity use cases #5513

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Initial set of use cases 
Signed-off-by: Peter Nied <petern@amazon.com>
  • Loading branch information
@peternied
peternied committed Jan 11, 2023
commit 1906092c039827e6d18eab9576e7574150193b2e
98 changes: 98 additions & 0 deletions IDENTITY_USE_CASES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
# Identity Use Cases in OpenSearch
- [Identity Use Cases in OpenSearch](#identity-use-cases-in-opensearch)
- [Non-use compatibility](#non-use-compatibility)
- [Scenario 1:](#scenario-1)
- [Identity features enabled](#identity-features-enabled)
- [Scenario 2:](#scenario-2)
- [Scenario 3:](#scenario-3)
- [Using Admin account](#using-admin-account)
- [Scenario 4:](#scenario-4)
- [Scenario 5:](#scenario-5)
- [Password changes](#password-changes)
- [Scenario 6:](#scenario-6)
- [Scenario 7:](#scenario-7)
- [Scenario 8:](#scenario-8)
- [Authenticate as new user](#authenticate-as-new-user)
- [Scenario 9:](#scenario-9)
- [Scenario 10:](#scenario-10)
- [Scenario 11:](#scenario-11)
- [Multi-node Cluster](#multi-node-cluster)
- [Scenario XXX:](#scenario-xxx)

## Non-use compatibility

Given: Start an OpenSearch cluster with Identity experiment enabled and not configured

### Scenario 1:

The cluster runs with the Security plugin. No Security plugin scenarios are impacted.

*Technical*: Identity uses the NoopAuthenticationManager

## Identity features enabled

Given: Start an OpenSearch cluster with Identity experiment enabled, internal identity is enabled in the configuration

### Scenario 2:

By reading the opensearch.log / console output a random admin password is shown.

### Scenario 3:

All REST API activity returns 403 without passing authentication information in the request

## Using Admin account
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want this to be the same level bold as the "Identity features enabled" and "Non-use compatibility" headers? Do you think it should be one level smaller to indicate that it is under the "Identity features enabled" group?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this works, but maybe it would make sense to have even more layers of depth. Would you want to re-write with an alternative layout? I'd be happy to accept a pull request

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that if you believe it is good as is, then it is just fine. I was more asking a question to see what you thought then expressing a major opinion one way or the other.


Given: The admin password is known

### Scenario 4:

Using http basic auth it is possible to make any REST API request, no errors related to authentication are seen.

### Scenario 5:

Admin makes a request to `PUT /identity/user/admin/password` with a json body `{ password: "value" }`, it succeeds

*Technical*: Need user actions

## Password changes

Given: The Admin password has been updated

### Scenario 6:

The admin's old password does not work on any REST API requests

### Scenario 7:

The admin's new password works for all REST API requests

### Scenario 8:

Admin user can create an account via `POST /identity/user/{username}`. The response includes an automatically generated password for this user.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

User should be able to edit their password. Should we add a scenario for password-recovery?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PUT /identity/user/{username}/password would work for any username if you had permission, would this cover your recovery scenario?


## Authenticate as new user

Given: The User's user name and password are know

### Scenario 9:

The user account can be accessed with http basic auth.

### Scenario 10:

`GET /identity/whoami` returns the username of the authenticated account
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we support this?. If so, for unauthenticated request, it should return 403, correct?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be some way of identifying who the current user is, and this is more/less what is already in OpenSearch. I think we can dive in on the behavior for other scenarios as well as additional use cases


### Scenario 11:

After the cluster is shutdown and restarted the accounts are still accessible as before

*Technical*: Need persistent storage


## Multi-node Cluster
Given: The OpenSearch cluster has more than one node

### Scenario XXX:

Admin makes a request to `PUT {NODE_1}/identity/user/admin/password` with a json body `{ password: "value" }`, it succeeds. Making a request to {NODE_2} requires the updated password, using the old password returns a 403 on REST API requests.