Re: [scim] SCIM Synchronization Problem

[Danny Mayer <[e-mail]>]

The cases I was describing were exactly access and permissions cases and 
was needed for audit and compliance purposes. In our cases the groups 
that were associated with the user accounts provided the permissions 
needed for each user.

Danny

On 8/20/21 11:31 AM, Phillip Hunt wrote:
> To be clear, the specs are written as protocol profiling HTTP.  The terms client and server stem from HTTP’s notion that a client initiates a request and a server responds.
>
> It is ok to develop a higher level in the information layer.  For example we had to adopt publish and subscribe for security events flow but the delivery specs talk about whether subscribers act as http clients or servers depending in whether events are pushed to them or whether they pull events from the publisher.
>
> Some of Danny’s requirements strike me as access control needs in scim service.  For example a client that authenticates with the correct scope may be allowed to return unlimited results in a request or may be allowed frequent polling requests. Another client may only be allowed to update or read specific claims at a certain rate.   Access control is something we can talk about in the charter (I have a proposal I can put together quickly in a draft)) but I would not support conflating access control with synchronization.
>
> The cases Danny is describing sound like a hybrid (of replica vs coordinated) where two domains are unequal but under a common authority.  This of course should be supported.
>
> The event model helps responsiveness in that subscribers can register to listen for changes as they occur.  As I mentioned previously I am happy to give a presentation on synchronous command (ie REST) vs async events and why this aids cross-domain synchronization performance and accuracy.
>
> Phil
>
>> On Aug 20, 2021, at 8:04 AM, Danny Mayer <[e-mail]> wrote:
>>
>> You cannot assume that the groups are the same across different application domains. In our case each group was totally different and had different permissions associated with it. In addition you can have different permissions associated individually to a user account. Microsoft's NTFS access controls are a good example of this.
>>
>> The SCIM Config information should include information on what commands are available on that system. In addition the application needs to notify the requestor that if something went wrong why it went wrong. For example, in my cases if a request for a group to be added to a user cannot be fulfilled because the group does not exist then the failure needs to be reported back. Also for our builtin and special accounts, the requestor cannot make any changes.
>>
>> Does this help?
>>
>> Danny
>>
>>> On 8/19/21 2:05 PM, Phillip Hunt wrote:
>>> This is good high level case information.
>>>
>>> Matt, you make a good case for access control standards. It brings out some questions…
>>>
>>> Is syncing users and groups enough or must access policy rules/data be synchronized (assuming a common standard for policy)?  How close must separate domains be to work this well together? Is it true that access control is the same across domains?
>>>
>>> These issues are what led me to believe client/server RESTful “command”s like POST/PUT/PATCH are insufficient. Instead, what if an event in one domain is published and a subscriber decides how to process the event? In command mode the requestor has to know the command will work. In event mode, the receiver has context to interpret and translate into local commands.
>>>
>>> Maybe we can do a con call and go through security events and how they support arms length cross domain relationships.
>>>
>>> Phil
>>>
>>>>> On Aug 19, 2021, at 10:33 AM, Matt Peterson (mpeterso) <Matt.Peterson=[e-mail]> wrote:
>>>> Thank you, Danny, for creating a new thread.  The following are my comments from meeting minutes (some edits):
>>>>
>>>> There appears to be two use cases for "synchronization":
>>>>
>>>>   1.  Constructing and enforcing Application authorization models -  An application (acting as a SCIM client) caches users/groups data from the IdP in order to present "user/group pickers" when presenting screens used to configure the application  authorization rules (RBAC, Policy, or ACL).  Also, when the application enforces authorization, user and group data needs to be immediately available so that authorization decisions can be made quickly.
>>>>
>>>>   2.  Identity Management and Governance systems - implement a canonical identity model" where all accounts and groups are represented.  This model is used to build provisioning rules and calculate separation of duty violations, attestations, and approvals etc.   Management-time evaluation of the model needs to be done efficiently without external calls to the SCIM service provider.
>>>>
>>>> Both above use cases, are "client-cache" use cases that need only a "one-way" sync (from the SCIM server to the SCIM client).   To accomplish there are two distinct steps:  a) download the initial results (users/groups) and, b) keep the cached copy of these initial results (user/groups) up to date with changes that are being made on the SCIM Service provider.
>>>>
>>>> I think it could help us narrow down the list of suitable approaches if we could agree that "one-way" sync (keeping a client-side cache up to date) is our target.
>>>>
>>>> --
>>>> Matt Peterson
>>>>
>>>> -----Original Message-----
>>>> From: scim <[e-mail]> On Behalf Of Danny Mayer
>>>> Sent: Wednesday, August 18, 2021 8:34 AM
>>>> To: SCIM WG <[e-mail]>
>>>> Subject: [scim] SCIM Synchronization Problem
>>>>
>>>> CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.
>>>>
>>>>
>>>> I decided that this needs it's own thread and not be part of the meeting minutes.
>>>>
>>>> I have had a great deal of experience dealing with the user account synchronization problem. Here's my view of the problems.
>>>>
>>>> I will be calling one system Management Server and the other system Application Server. I found client/server labels confusing. The Management Server is what I am defining to be the server that sends updates to add/update/remove users and groups to the Application server whose account, groups and access permissions are being managed.
>>>>
>>>> First some definitions of user accounts. There are usually more than one of each of these:
>>>> 1. Builtin accounts
>>>> 2. Special-purpose accounts
>>>> 3. Employee
>>>> 4. Contractor
>>>> 5. Agent
>>>> 6. Customer
>>>>
>>>> There may be more.
>>>>
>>>> 1. Builtin accounts: These are accounts that applications have and there may be more than one. There is always an admin account which can do anything, for example the administrator account in Active Directory or a database admin account. The application may have more accounts for other purposes.
>>>>
>>>> 2. Special-purpose accounts: These may be set up to provide access to other applications, for example a SCIM request to a SCIM REST API should be handled by a special account which cannot be used to login via a UI interface and only be able to perform certain functions. In addition there may be accounts set up to listen for topics or queues on a message queue among other possibilities. Keeping separate accounts like this are important for tracking in logs and applications.
>>>>
>>>> 3. Employee: These are accounts that employees may login to the application.
>>>>
>>>> 4. Contractors: These accounts that a contractor performing work for the company may use to log into an application. Unlike Employee accounts these would have an expiration date.
>>>>
>>>> 5. Agent: Accounts like this are for external users who may need to manage information for their own customers. An example of this is an insurance agent logging in to handle an insurance policy for their clients.
>>>>
>>>> 6. Customers: These are where the customers are using the application directly. For a bank it's likely to be millions of customers. The management platform should not be involved in managing these accounts.
>>>>
>>>> Let's now look at a few example applications.
>>>>
>>>> 1. Helpdesk
>>>> All employees and contractors will need to be able to log into a helpdesk application and enter tickets. This means loading information about all employees and contractors. For a company with only 1000 employees that's manageable. For a company with 100K employees, it's a bigger challenge.
>>>>
>>>> 2. Customer Support
>>>> Only employees or contractors in the department providing customer support need access plus a few other employees. In addition identified customers may need accounts.
>>>>
>>>> 3. Expenses
>>>> Not all employees or contractors will be submitting expenses so it may not be necessary to have accounts for all possible users. This is something that the application owner needs to decide.
>>>>
>>>> Now let's look at logistics.
>>>>
>>>> Bulk load:
>>>> Each application will need an initial set of accounts set up and for something like a helpdesk this could involve load 1000-100,000 accounts.
>>>> The information needed could come from either the management server or separately, say from an HR system. Many servers that I have encountered limit the number of records to something like 1000, so the pagination requirement is needed for this. Even when dealing with a limited subset of employees or contractors you can run into this need.
>>>>
>>>> Synchronization
>>>> An application that is bulk-loaded above may need to be synchronized to the management server if the data did not come from the management server.
>>>>
>>>> Change Management
>>>> This is really a synchronization issue as well. Changes happen all the time and new employees/contractors need to be added, terminated ones removed and updates happen all the time. The best way of dealing with this may be to set up a message queue that each application can subscribe to and they can take the needed action when it's convenient for that application. It's not the only method but it's the one I found to be the most helpful. There are two ways of doing that: 1. send the complete user information for new accounts, send just the change for updating accounts, send the ID for terminated accounts along with some meta information. The other method which I have used is just to send the ID and whether it's new, updated or terminated.
>>>>
>>>> I hope this is helpful to the discussion.
>>>>
>>>> Danny
>>>>
>>>>
>>>> _______________________________________________
>>>> scim mailing list
>>>> [e-mail]
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&amp;data=04%7C01%7Cmatt.peterson%40quest.com%7C1fb1fe803b8c439026bd08d9625553ba%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637648940889425726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=riJQy3jEHltc6ZFCaEe%2B6%2F2ecXN0SWBXOxIZAKLxum4%3D&amp;reserved=0
>>>>
>>>> _______________________________________________
>>>> scim mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/scim