You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When views are accessed data shall be provided to downstream systems to reason if a request is authorized or not. While identity work has started in OpenSearch plugins such as the Security plugin are the current standard for access control - modification to the existing identity interfaces is out of scope for this effort.
Create a mechanism to allow for requests to convey the resource that is being accessed and the identifier of this resource, in this case a view and the view_id, but this could be a machine learning model and its id or a credential and its identifier. This issue contains an initial proposal built in a proof of concept, but is not hard requirements for the feature.
[Proposal 1] Resource Request
In order to permissions views OpenSearch needs a way to consistently refer to them, this is a generic problem and views will be a first use case. Resource requests require a map of types to identifiers for the request, multiple resources could be part of a single request, but only one of each type.
Considering the request to search a view, POST /view/{view_id}/_search, the path parameter 'view_id' is the type and the value from the request would be the identifier.
publicinterfaceResourceRequest {
/** Returns the resource types and ids associated with this request */Map<String, String> getResourceTypeAndIds();
/** Validates the resource type and id pairs are in an allowed format */publicstaticActionRequestValidationExceptionvalidResourceIds(
finalResourceRequestresourceRequest,
finalActionRequestValidationExceptionvalidationException
) {;}
}
It would be ideal if this information could be accessed at the RestLayer - less resources spent on rejected requests - but at the TransportLayer will also be needed.
Exit Criteria
Resource interfaces
Resource validation patterns
Expose resource type & id mappings to downstream system
The text was updated successfully, but these errors were encountered:
[Triage] This is related to the same linked RFC and prototype for resource based permissions. We can mark this as triaged.
stephen-crawford
added
triaged
Issues labeled as 'Triaged' have been reviewed and are deemed actionable.
and removed
untriaged
Require the attention of the repository maintainers and may need to be prioritized
labels
Jan 8, 2024
Description
When views are accessed data shall be provided to downstream systems to reason if a request is authorized or not. While identity work has started in OpenSearch plugins such as the Security plugin are the current standard for access control - modification to the existing identity interfaces is out of scope for this effort.
Create a mechanism to allow for requests to convey the resource that is being accessed and the identifier of this resource, in this case a view and the view_id, but this could be a machine learning model and its id or a credential and its identifier. This issue contains an initial proposal built in a proof of concept, but is not hard requirements for the feature.
[Proposal 1] Resource Request
In order to permissions views OpenSearch needs a way to consistently refer to them, this is a generic problem and views will be a first use case. Resource requests require a map of types to identifiers for the request, multiple resources could be part of a single request, but only one of each type.
Considering the request to search a view,
POST /view/{view_id}/_search
, the path parameter 'view_id' is the type and the value from the request would be the identifier.It would be ideal if this information could be accessed at the RestLayer - less resources spent on rejected requests - but at the TransportLayer will also be needed.
Exit Criteria
The text was updated successfully, but these errors were encountered: