[
https://issues.apache.org/jira/browse/AIRAVATA-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629527#comment-16629527
]
ASF subversion and git services commented on AIRAVATA-2840:
-----------------------------------------------------------
Commit 61570055211a4bb742c57120d736fe338e81b4fb in airavata-php-gateway's
branch refs/heads/develop from [~marcuschristie]
[ https://gitbox.apache.org/repos/asf?p=airavata-php-gateway.git;h=6157005 ]
AIRAVATA-2840 Updates for API changes
> Group-based authz applied to credential store tokens (was: Secure
> GroupResourceProfiles from being cloned and repurposed)
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: AIRAVATA-2840
> URL: https://issues.apache.org/jira/browse/AIRAVATA-2840
> Project: Airavata
> Issue Type: Bug
> Reporter: Marcus Christie
> Assignee: Marcus Christie
> Priority: Major
>
> Email to dev list:
> {quote}
> Hi All,
> I’m looking for some advice on how to secure GroupResourceProfiles. The
> problem is this: any user that has READ access to a GroupResourceProfile can
> effectively clone that GroupResourceProfile. This would allow the user to
> create a new GroupResourceProfile that uses the same login/allocation and
> this new GroupResourceProfile could have fewer restrictions or be shared with
> other users.
> Here are some solutions I’m considering:
> 1. Create a new permission type that is less privileged than READ and that
> gives access to less details. There are a few details in the
> GroupComputeResourcePreferences that are sensitive, like loginUserName,
> resourceSpecificCredentialToken and allocationProjectNumber, because these
> fields determine what account gets charged and these could be left out.
> 2. Hide the sensitive fields mentioned above from users with READ access and
> only show them to users with WRITE access.
> 3. Apply group based authorization to credential tokens and require new
> GroupResourceProfiles to have their own credential tokens, that would only be
> accessible to the user that creates the GroupResourceProfile.
> I’m open to other ideas. I’m leaning toward #2. The problem with #1 is it
> introduces another permission type (READ, WRITE and “USE”?) that will
> complicate the user experience. #3 also complicates what is required to
> create a GroupResourceProfile. One use case we have in mind is that users who
> create a GroupResourceProfile can leverage defaults defined in the
> GatewayResourceProfile and thus only need to provide an allocation project
> number and not need to add an SSH key to a compute resource account. Approach
> #3 would make that more difficult or impossible.
> I hope the above makes sense. Let me know if you have any questions.
> Thanks,
> Marcus
> {quote}
> h2. Proposed API methods
> * (breaking change) generateAndRegisterSSHKeys(authzToken, description)
> * (breaking change) registerPwdCredential(authzToken, loginUserName,
> password, description)
> * (new) getCredentialSummary(authzToken, tokenId)
> * (new) getAllCredentialSummaries(authzToken, type)
> * remove getSSHPubKey - use getCredentialSummary instead
> * remove getAllGatewaySSHPubKeys - use getAllCredentialSummaries instead
> * remove getAllCredentialSummaryForGateway - use getAllCredentialSummaries
> instead
> * remove getAllCredentialSummaryForUsersInGateway - use
> getAllCredentialSummaries instead
> * remove getAllGatewayPWDCredentials - use getAllCredentialSummaries instead
> * (modified) deleteSSHPubKey - remove gatewayId parameter
> * (modified) deletePWDCredential - remove gatewayId parameter
> h2. Proposed Credential Store CPI methods
> * (new) getAllCredentialSummaries(type, accessibleTokenIds, gatewayId)
> * -remove getAllCredentialSummaryForGateway- keeping because it is needed for
> migration, marking *deprecated*
> * -remove getAllCredentialSummaryForUserInGateway- keeping because it is
> needed for migration, marking *deprecated*
> * remove getAllSSHKeysForUser
> * remove getAllSSHKeysForGateway
> * -remove getAllPWDCredentialsForGateway- keeping because it is needed for
> migration, marking *deprecated*
> h2. Proposed data model changes
> * remove CredentialOwnerType. The credential owner will be registered in the
> sharing registry. "GATEWAY" credentials will be those created and shared with
> users in the Admins group. Credentials that users create will be visible to
> admins as well and anyone else they want.
> h2. TODO
> * [x] Update migration script
> * [x] Test migration script
> * [x] Add {{getAllCredentialSummaries(type, accessibleTokenIds, gatewayId)}}
> to credential store
> * [x] Update API server methods to register credentials with sharing registry
> and query sharing registry for allowed credentials
> * [x] Update API methods that take an object with credential tokens and
> verify that that user has access to those credential tokens. For example,
> createGroupResourceProfile takes as input a GroupResourceProfile object. This
> object contains GroupComputeResourcePreference objects that may specify a
> resourceSpecificCredentialToken. {{createGroupResourceProfile}} should
> validate that the user has access to every resourceSpecificCredentialToken
> and throw an AuthorizationException if not.
> * [ ] passwords UI in credential store
> * [ ] getCredentialSummary with just token id (backend can just figure out
> the type)
> * [ ] remove gatewayId from delete methods
> * [ ] sort the ssh and password credentials by name
> * [ ] add sharing button to credentials UI
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
