You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@airavata.apache.org by "Marcus Christie (JIRA)" <ji...@apache.org> on 2018/10/12 22:09:00 UTC
[jira] [Updated] (AIRAVATA-2908) Improve SecurityCheck, generalize
it, and apply to Profile Service API methods
[ https://issues.apache.org/jira/browse/AIRAVATA-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcus Christie updated AIRAVATA-2908:
--------------------------------------
Description:
Profile Service methods are annotated with @SecurityCheck but the Profile Service isn't configured with an interceptor like AiravataServerHandler: https://github.com/apache/airavata/blob/970dc68e659daf8d633e7aaeb6dceaac063d6725/airavata-api/airavata-api-server/src/main/java/org/apache/airavata/api/server/AiravataAPIServer.java#L186-L186, so it isn't really doing anything.
But just wiring up the interceptor won't work. We need to rethink what @SecurityCheck is doing. The KeyCloakSecurityManager is written such that it whitelists several API server methods, but that approach won't scale if we start adding other services.
I would like to see @SecurityCheck/SecurityInterceptor do the following:
* validate the token and store that in the cache up to the token expiration time
* if an API method is annotated with {{@SecurityCheck}} then it simply checks the token
* if an API method is annotated with {noformat}@SecurityCheck(groups={ADMIN, READ_ONLY_ADMIN}){noformat} then it checks the GatewayGroups to see if the user is in one of those groups
This will allow us to simplify KeyCloakSecurityManager: it won't need to have a whitelist of API methods and the group based auth on an API method is configured right on the method.
For example, in API server
{code:java}
@Override
@SecurityCheck(groups={ADMIN})
public boolean deleteComputeResource(AuthzToken authzToken, String computeResourceId) throws InvalidRequestException,
AiravataClientException, AiravataSystemException, AuthorizationException, TException {
...
}
{code}
Some other thoughts:
* NOTE: the Profile Service may end up being broken out into a separate security project ("Custos"), so this may not be necessary. However, there are definite benefits to the API server too and future public APIs
* We could keep going with this and have @SecurityCheck also check the sharing registry. We would need to annotate the API method parameter that is the entity id and also provide the required permission, for example:
{code:java}
@Override
@SecurityCheck(permission=READ)
public ExperimentModel getExperiment(AuthzToken authzToken, @SharingEntityId String airavataExperimentId) throws InvalidRequestException,
ExperimentNotFoundException, AiravataClientException, AiravataSystemException, AuthorizationException, TException {
...
}
{code}
was:
Profile Service methods are annotated with @SecurityCheck but the Profile Service isn't configured with an interceptor like AiravataServerHandler: https://github.com/apache/airavata/blob/970dc68e659daf8d633e7aaeb6dceaac063d6725/airavata-api/airavata-api-server/src/main/java/org/apache/airavata/api/server/AiravataAPIServer.java#L186-L186, so it isn't really doing anything.
But just wiring up the interceptor won't work. We need to rethink what @SecurityCheck is doing. The KeyCloakSecurityManager is written such that it whitelists several API server methods, but that approach won't scale if we start adding other services.
I would like to see @SecurityCheck/SecurityInterceptor do the following:
* validate the token and store that in the cache up to the token expiration time
* if an API method is annotated with {{@SecurityCheck}} then it simply checks the token
* if an API method is annotated with {{@SecurityCheck(groups={ADMIN, READ_ONLY_ADMIN})}} then it checks the GatewayGroups to see if the user is in one of those groups
This will allow us to simplify KeyCloakSecurityManager: it won't need to have a whitelist of API methods and the group based auth on an API method is configured right on the method.
For example, in API server
{code:java}
@Override
@SecurityCheck(groups={ADMIN})
public boolean deleteComputeResource(AuthzToken authzToken, String computeResourceId) throws InvalidRequestException,
AiravataClientException, AiravataSystemException, AuthorizationException, TException {
...
}
{code}
Some other thoughts:
* NOTE: the Profile Service may end up being broken out into a separate security project ("Custos"), so this may not be necessary. However, there are definite benefits to the API server too and future public APIs
* We could keep going with this and have @SecurityCheck also check the sharing registry. We would need to annotate the API method parameter that is the entity id and also provide the required permission, for example:
{code:java}
@Override
@SecurityCheck(permission=READ)
public ExperimentModel getExperiment(AuthzToken authzToken, @SharingEntityId String airavataExperimentId) throws InvalidRequestException,
ExperimentNotFoundException, AiravataClientException, AiravataSystemException, AuthorizationException, TException {
...
}
{code}
> Improve SecurityCheck, generalize it, and apply to Profile Service API methods
> ------------------------------------------------------------------------------
>
> Key: AIRAVATA-2908
> URL: https://issues.apache.org/jira/browse/AIRAVATA-2908
> Project: Airavata
> Issue Type: Improvement
> Reporter: Marcus Christie
> Priority: Major
>
> Profile Service methods are annotated with @SecurityCheck but the Profile Service isn't configured with an interceptor like AiravataServerHandler: https://github.com/apache/airavata/blob/970dc68e659daf8d633e7aaeb6dceaac063d6725/airavata-api/airavata-api-server/src/main/java/org/apache/airavata/api/server/AiravataAPIServer.java#L186-L186, so it isn't really doing anything.
> But just wiring up the interceptor won't work. We need to rethink what @SecurityCheck is doing. The KeyCloakSecurityManager is written such that it whitelists several API server methods, but that approach won't scale if we start adding other services.
> I would like to see @SecurityCheck/SecurityInterceptor do the following:
> * validate the token and store that in the cache up to the token expiration time
> * if an API method is annotated with {{@SecurityCheck}} then it simply checks the token
> * if an API method is annotated with {noformat}@SecurityCheck(groups={ADMIN, READ_ONLY_ADMIN}){noformat} then it checks the GatewayGroups to see if the user is in one of those groups
> This will allow us to simplify KeyCloakSecurityManager: it won't need to have a whitelist of API methods and the group based auth on an API method is configured right on the method.
> For example, in API server
> {code:java}
> @Override
> @SecurityCheck(groups={ADMIN})
> public boolean deleteComputeResource(AuthzToken authzToken, String computeResourceId) throws InvalidRequestException,
> AiravataClientException, AiravataSystemException, AuthorizationException, TException {
> ...
> }
> {code}
> Some other thoughts:
> * NOTE: the Profile Service may end up being broken out into a separate security project ("Custos"), so this may not be necessary. However, there are definite benefits to the API server too and future public APIs
> * We could keep going with this and have @SecurityCheck also check the sharing registry. We would need to annotate the API method parameter that is the entity id and also provide the required permission, for example:
> {code:java}
> @Override
> @SecurityCheck(permission=READ)
> public ExperimentModel getExperiment(AuthzToken authzToken, @SharingEntityId String airavataExperimentId) throws InvalidRequestException,
> ExperimentNotFoundException, AiravataClientException, AiravataSystemException, AuthorizationException, TException {
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)