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.

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

Add support for "expiry" of policy subjects #890

Closed
thjaeckle opened this issue Nov 20, 2020 · 0 comments · Fixed by #929
Closed

Add support for "expiry" of policy subjects #890

thjaeckle opened this issue Nov 20, 2020 · 0 comments · Fixed by #929
Milestone

Comments

@thjaeckle
Copy link
Member

In order to give access for a certain "authorized subject" only until a fixed timestamp, a Policy subject shall be optionally provided with an "expiry" timestamp (being an ISO-8601 string).

Once the "expiry" timestamp was reached, the subject shall be automatically removed from the policy (that change being persisted) and as a result this subject would immediately no longer have access.

Example Policy:

{
  "policyId": "my.namespace:policy-a",
  "entries": {
    "owner": {
      "subjects": {
        "nginx:house-owner-user": {
          "type": "This is the owner of the house"
        },
        "nginx:neighbor-user": {
          "type": "This is the neighbor which shall manage the smart house during a vacation",
          "expiry": "2020-11-26T11:00Z"
        }
      },
      "resources": {
        "thing:/": {
          "grant": [
            "READ",
            "WRITE"
          ],
          "revoke": []
        },
        "policy:/": {
          "grant": [
            "READ",
            "WRITE"
          ],
          "revoke": []
        },
        "message:/": {
          "grant": [
            "READ",
            "WRITE"
          ],
          "revoke": []
        }
      }
    }
  }
}
@thjaeckle thjaeckle added this to the 1.5.0 milestone Nov 20, 2020
@thjaeckle thjaeckle removed this from the 1.5.0 milestone Dec 1, 2020
@thjaeckle thjaeckle added this to the 2.0.0 milestone Dec 9, 2020
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…SujectExpiry`

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…ct with SubjectExpiry

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…d up" passed in subject expiry

* made the granularity to apply configurable in PolicyConfig
* added unit tests for PolicyCommandStrategies for the affected strategies applying the rounding up of subject expiries
* adjusted the PolicyValidator to make sure that configured subject expiries are not in the past

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
* added "expiry" as well to Policy JsonSchema
* did some cleanup in OpenAPI docs while at it (e.g. moving schemas to subfolders)

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
* applied double checked locking in PolicyCommandStrategies
* simplified adjusting a PolicyEntry with adjusted subjects
* fixed that an already pre-"rounded/truncated" subject expiration was rounded up to the next unit where it should not have

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…eteSubject event when

* the next subject will expire
* re-schedule when after the expired subject deletion there are still other subjects to expire
* added tests, fixed etag calculation which must be done based on the adjusted command (e.g. with rounded up expiry timestamp)

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…imezones correctly

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
* added unit test for correct expiration after actor restart/recovery

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…never the PolicyPersistenceActor publishes a PolicyTag message

* this PolicyTag message is published when an in the concierge processed PolicyCommand did not result already in a cache validation
* as a result, the "DeleteSubject" event which is created in the background by the expiry feature will cause the concierge policy enforcer cache to invalidate

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…icy enforcer caches in concierge whenever the PolicyPersistenceActor publishes a PolicyTag message

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai added a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…iption; fix broken link in cloudevent openapi.

Signed-off-by: Yufei Cai <yufei.cai@bosch.io>
yufei-cai added a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…ned expiry; add TODO.

Signed-off-by: Yufei Cai <yufei.cai@bosch.io>
yufei-cai added a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…as warning.

Signed-off-by: Yufei Cai <yufei.cai@bosch.io>
yufei-cai added a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…ctDeleted events; optimize PolicyEventForwarder to not query database in the absence of policy changes.

Signed-off-by: Yufei Cai <yufei.cai@bosch.io>
yufei-cai added a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…ix PolicyCommandEnforcementTest.

Signed-off-by: Yufei Cai <yufei.cai@bosch.io>
yufei-cai added a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…ctsStrategyTest.

Signed-off-by: Yufei Cai <yufei.cai@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
* return status code 400 instead of 403 when trying to use an expiry TS from the past
* ensure that a recovery first removes expired subjects before applying further commands
* cope with expiry timestamps in a distant future (>8 months from now) as those caused long-overflow exceptions: reschedule checking after 1 day in such cases

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
* simplified scheduling of next expiry check
* added missing javadoc
* deduplicated scheduling

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai pushed a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
* further simplified scheduling of next expiry check
* added unit test ensuring that an already expired subject is deleted during persistence recovery

Signed-off-by: Thomas Jaeckle <thomas.jaeckle@bosch.io>
yufei-cai added a commit to bosch-io/ditto that referenced this issue Dec 23, 2020
…xpiryIsCleanedUpAfterRecovery

- Kill the persistence actor right away, so that it has no chance
  to delete the expired subject before termination

- Test the persistence actor in a shard region in order for
  SudoRetrievePolicy to be the first message the actor processes
  when restored.

Signed-off-by: Yufei Cai <yufei.cai@bosch.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant