search

SecureIdentityAlliance / osia

Open Standard set of APIs for interoperability of identity management building blocks.
https://osia.readthedocs.io/en/latest/
Other
21 stars 20 forks source link

Define security scheme & authorization #16

Closed olivier-heurtier-idemia closed 4 years ago

petr-sturc-thales commented 4 years ago

I see that typically there is only .read and .write scope defined, but no .delete scope. Don't you think that delete operation should have separate scope? Intuitively - modifying en existing identity or enrollment is quite different thing from completely erasing something.

petr-sturc-thales commented 4 years ago

The authorization scopes are related only to actions, but it doesn't allow any segregation of data in the sense e.g. regional or organizational segregation. Shouldn't OSIA also address that? As example - we have seen cases where we should allow only access the "enrollments" created by the same officer or same office, but disallow to see data created elsewhere, unless you have special privilege.

olivier-heurtier-idemia commented 4 years ago

The authorization scopes are related only to actions, but it doesn't allow any segregation of data in the sense e.g. regional or organizational segregation. Shouldn't OSIA also address that? As example - we have seen cases where we should allow only access the "enrollments" created by the same officer or same office, but disallow to see data created elsewhere, unless you have special privilege.

You are perfectly right but we explicitely excuded ACL (Access Control List) from the current scope of OSIA. It maybe added in a later version of course.

olivier-heurtier-idemia commented 4 years ago

I see that typically there is only .read and .write scope defined, but no .delete scope. Don't you think that delete operation should have separate scope? Intuitively - modifying en existing identity or enrollment is quite different thing from completely erasing something.

I was inspired by various existing public REST API, such as Google or Facebook API, and it seems to be the trend to define one scope for read (only) access and one scope for all the modification (create, update & delete). It is also our interest to keep the list of scopes as small as possible so that they can fit in a bearer token within the limit of what HTTP servers accept (usually something like 4KB).