(Marcus Hardt)
What is it about? We are happy to get the users in the system, but we do not want them there all the time. Some systems require first provisioning of accounts, for example Open Stack, Unix-accounts - they all rely on proprietary login mechanisms
Example of an architecture to illustrate the problem:
+-----------+
| home idp |
+-----------+
/ / \ \
/ +---------+ \
/ |BPA Proxy| <= Group management
/ +---------+ \
/ / \ \
+----------------------+ \ \
| Provisioning service | \ \
+----------------------+ \ \
| | \ \
+------------------+ +----------+
| Unix shell / SSH | | Owncloud | <= (end) services
+------------------+ +----------+
Problem: Users can access their services without visiting the home-IdP. Updated attributes might not arrive at the services. Users that left their home org will still be able to access resources.
Current state: Users are asked to authenticate in intervals otherwise they are blocked (VMs stopped, Unix acts suspended etc.) -> users will be annoyed.
Rotating attribute queries to home IdPs (if supported) –> scalability issues, GDPR conflicts?
Discussion: Are there ways out?
It depends on what you want to do. There must be some proxy in between the home IdP and the services.
Deprovisioning use case would in any case need to have updated info on the user. End services should have some way to get user updates - something more user friendly than blocking access in a regular basis.
Refresh tokens are a solution - it can be revoked at any time and the refresh is up to a limited time span.
Downside: VM will run even without a refresh token - OpenStack should solve this, it keeps track of the local user. On the lower level you only want the updated info on the user.
It is an application specific problem!
Problem: university system, student user turns into faculty staff – has more access. Could create a generic solution: university sets up an endpoint, an API to query if the user is still in the repository or not. Paid solutions can be managed via human intervention - paying for the service / infrastructure provides an incentive to check.
Real example: OpenStack cloud - checks are done manually at the moment. Check how long the service has been on and look for resources being used. It informs the user and if they do not respond, the resource will be shifted and further totally removed. It is done via automated scripts in dedicated slack channel which will send out these messages. There is a dedicated person who checks this from time to time.
Users are happy to receive emails with the IDs of users that are deprovisioned - not automated APIs querying and selecting information.
Why not SCIM? Provides REST API, supports push and pull operations. It is a standard technology, provides same interface to all incoming users. Downsides: It is an additional interface to implement & it has a rigid schema, which does not fit all services and if it will be expanded it turns into a completely custom implementation -> interoperability issues.
Scalability of attribute queries - question if IDPs will set attributes for services to query? Does it violate the GDPR? As an SP you have to be part of the federation but otherwise it should be possible.
Another aspect of the issue: does the user exist? SCIM can be used to prove this. Sending SCIM delete request to the IdP and IdP will then forward this request to other services. Should be widely implemented.
SIRTIFI requires that IdPs keep a list of SPs to be notified in case of incident. Automation of the process would be very helpful here!
Big cloud providers do share security incidents within themselves. Probably helpful to have a look at that information!
