eric/SBS

Watch

Fork 0

As an application provider, I want to signal SRAM of activity, so the collaboration and user are kept active #1719

New issue

Open

opened 2024-12-02 10:19:18 +00:00 by FlorisFokkinga · 8 comments

FlorisFokkinga commented

2024-12-02 10:19:18 +00:00

(Migrated from github.com)

Alternatively: As an admin of an app storing data, I want collaborations to remain, even if the are inactive and have no members

To not retain PII unecessarily, SBS suspends collaborations which are inactive for 12 months and informs the CO Admin and/or Organisation Admin. If we do not get any reply, and if the CO remains inactive for another 3 moths, SBS deletes the collaboration.

SBS only knows about logins to applications if SAML or OIDC is used. For example: if an application uses LDAP and users log in using an SSH key, SBS doesn't know about logins. Editing a collaboration also marks them active for a year.

I suppose the question here is if, and under what conditions, we want to trust applications to mark collaborations active.

Possible solution: don't delete an collaboration for inactivity if they have an expiry date. But do suspend it?

Alternatively: As an admin of an app storing data, I want collaborations to remain, even if the are inactive and have no members To not retain PII unecessarily, SBS suspends collaborations which are inactive for 12 months and informs the CO Admin and/or Organisation Admin. If we do not get any reply, and if the CO remains inactive for another 3 moths, SBS deletes the collaboration. SBS only knows about logins to applications if SAML or OIDC is used. For example: if an application uses LDAP and users log in using an SSH key, SBS doesn't know about logins. Editing a collaboration also marks them active for a year. I suppose the question here is if, and under what conditions, we want to trust applications to mark collaborations active. Possible solution: don't delete an collaboration for inactivity if they have an expiry date. But do suspend it?

logan-life commented

2025-03-07 08:09:50 +00:00

(Migrated from github.com)

From our Privacy Policy

SURF as a data processor: SURF acts as a data processor for the Organizations for all processing activities relating to the COs insofar SRAM is involved. A CO is always connected to an Organization in SRAM. The Organization to which the CO is connected is the data controller regarding these processing activities. SURF is an intermediary in this process. Mind that SURFs role is limited. SURF does not determine the way different institutions and organizations work together in a CO.

Data regarding the CO (name of the CO, groups within the CO, membership of the CO, services connected to the CO):
In case an organisation or CO-admin requests to delete the CO, SURF will hide the data from all users except the platform managers. SURF will verify whether deleting the CO is indeed what the organsation responsible for the CO wants, and delete the CO data within 8 weeks.
If we don't see any activity in relation to a CO for 12 months, SURF will send out an email to the CO-admin and/or the Organisation contact person whether they want us to delete the CO. If we don't get a reply within 3 months nor do we see any activity regarding the CO within those 3 months, SURF will delete the CO.

From our [Privacy Policy](https://servicedesk.surf.nl/wiki/spaces/IAM/pages/117178721/Privacy+policy+SRAM) > SURF as a data processor: SURF acts as a data processor for the Organizations for all processing activities relating to the COs insofar SRAM is involved. A CO is always connected to an Organization in SRAM. The Organization to which the CO is connected is the data controller regarding these processing activities. SURF is an intermediary in this process. Mind that SURFs role is limited. SURF does not determine the way different institutions and organizations work together in a CO. > Data regarding the CO (name of the CO, groups within the CO, membership of the CO, services connected to the CO): In case an organisation or CO-admin requests to delete the CO, SURF will hide the data from all users except the platform managers. SURF will verify whether deleting the CO is indeed what the organsation responsible for the CO wants, and delete the CO data within 8 weeks. If we don't see any activity in relation to a CO for 12 months, SURF will send out an email to the CO-admin and/or the Organisation contact person whether they want us to delete the CO. If we don't get a reply within 3 months nor do we see any activity regarding the CO within those 3 months, SURF will delete the CO.

logan-life commented

2025-03-07 08:11:16 +00:00

(Migrated from github.com)

Question: What is the impact of suspending a collaboration?

logan-life commented

2025-03-07 08:45:28 +00:00

(Migrated from github.com)

Possibly we can consider things like:

Increase the suspension status period from 3 months to 12 months and send more frequent reminders
Add a dynamically appearing tab (similar to the Application Connection Requests tab) that appears for Soon To Be Suspended and/or Soon To Be Deleted collaborations. This would appear for CO Admins and above. It would have a button to easily mark the CO as active and reset the clock on the suspension/deletion cycle.
For the application side, consider allowing this via Org side procedures, and not from the application admin/manager. In other words, applications should not have the power to say anything about the activity of a CO. But if the CO is within a Unit that the application admin is a Unit manager for, then great, go for it, using the tab as above. Otherwise, the power to say what a CO status is should be with the Org and all roles under the Org admin.

To think about this more...

Possibly we can consider things like: - Increase the `suspension` status period from 3 months to 12 months and send more frequent reminders - Add a dynamically appearing tab (similar to the Application Connection Requests tab) that appears for `Soon To Be Suspended` and/or `Soon To Be Deleted` collaborations. This would appear for CO Admins and above. It would have a button to easily mark the CO as active and reset the clock on the suspension/deletion cycle. - For the application side, consider allowing this via Org side procedures, and not from the application admin/manager. In other words, applications should not have the power to say anything about the activity of a CO. But if the CO is within a Unit that the application admin is a Unit manager for, then great, go for it, using the tab as above. Otherwise, the power to say what a CO status is should be with the Org and all roles under the Org admin. To think about this more...

logan-life commented

2025-05-02 09:59:27 +00:00

(Migrated from github.com)

@logan-life look at some other community AAIs that support non-web cases and see if they have solved this.

@logan-life to look at the privacy policy and implications of changing the suspension period.

@logan-life look at some other community AAIs that support non-web cases and see if they have solved this. @logan-life to look at the privacy policy and implications of changing the suspension period.

logan-life commented

2025-10-02 13:59:17 +00:00

(Migrated from github.com)

Via #2058, a Collaboration Expiry Date will take precedence over inactivity.

Doesn't solve the problem of inactivity false positives on applications that don't signal to SRAM. To be discussed more in tech refinement.

Via #2058, a Collaboration Expiry Date will take precedence over inactivity. Doesn't solve the problem of inactivity false positives on applications that don't signal to SRAM. To be discussed more in tech refinement.

logan-life commented

2025-10-03 09:55:13 +00:00

(Migrated from github.com)

Discussed in tech refinement today. Possibly a solution via application tokens + new endpoint on SBS side. @HarryKodden will update this ticket with more details on possible solution.

HarryKodden commented

2025-10-08 14:09:06 +00:00

(Migrated from github.com)

Example:

curl -X POST https://<sbs-url>/api/user-active
- H Authrorization: Bearer <service_token>
- d '{ "username": "<uid>" }'

The idea is that: If the user authenticates with the service bypassing re-authentication with SRAM, the service can signal that user activeness back to SRAM.

The effect of this call should be that the last-seen time stamp of this user is updated.

for Services that allow users to authenticate to the Service via SRAM and from that moment on make use of the Service without re-authenticating again (frequently), it can happen that SRAM considers these service - users as non-active users. This is because SRAM does not 'see' them. To prevent these users to get suspended, we could create an Service endpoint that requires a Service Token and that the Service can use to signal the activeness of a user. Example: ``` curl -X POST https://<sbs-url>/api/user-active - H Authrorization: Bearer <service_token> - d '{ "username": "<uid>" }' ``` The idea is that: If the user authenticates with the service bypassing re-authentication with SRAM, the service can signal that user activeness back to SRAM. The effect of this call should be that the last-seen time stamp of this user is updated.

FlorisFokkinga commented

2026-03-09 13:32:47 +00:00

(Migrated from github.com)

@HarryKodden @logan-life en @EricvanSchaik gaan dit samen refinen