Re: [scim] Contributors needed for HR schema

[Phillip Hunt <[e-mail]>]

There are a few aspects I see with this subject…

1. Standardized schema. If HR vendors are going to build a common connector scim might be a candidate. The primary need for schema is to create a common definition that every one can work with. 

2. Life-cycles,  the life cycle of an employee, contractor, etc may be different than a user account. 

3.  Access control. In the case of SCIM, HTTP provides the common signaling between clients and servers (eg http unauthorized status etc).  

Instead, the access model that implements access decisions is up to the implementer.  The interop of rules would only be needed if access control data was exchanged through the front channel as it was with some ldap systems.  IMO putting acis in the front channel may not be the best from a security perspective. Access control should be handled via an administrative api.  Thats just my thought.  As an example, i2scim.io supports two and soon 3 access systems. It has had to support an updated ldapaci model for internal enforcement, Open Policy Agent (OPA) for external integration and am now considering Hexa IDQL (https://www.cncf.io/projects/hexa/).  I think my point being, lets not define yet another access policy language.  It seems to me that externalized policy administration and governance is likely to trend in the market and beyond the scope of our group. 

—> In other words, don’t get bogged down on the data access model for HR. Just focus on the likely common requirements that implementers should/must ensure.  It is always up to the deployers to work with their legal council to ensure relevant compliance. 

4. Extension mechanism. You could use extended schema (like enterprise user) to add HR attributes. I see two downsides with this approach:  access controls will be much more complex because only a few clients should have access to see and update this data. This might adversely impact performance in security systems that need fast access to User resources. 

Another approach would be to create new resource types (eg hrPerson) that may reference Users.  This would enable more restricted access to hrPerson resources and allow for differing entity lifecycles.  It also avoids accidental release of information when a client retrieves a user resource not needing HR data. 

5.  API or directory:  it is also important to consider whether scim is just an API supported by an HR system or whether SCIM acts as a “directory” an HR system coordinates with. Obviously this can influence many of the choices above (such as extension mechanism). 

In a co-ordinated deployment, using scim events can help support the appropriate de-coupling between information systems that is needed. I would avoid meta-directory style approaches that many of us old timers went through 20 years ago. 😵‍💫

Hope this info dump helps!

Phil

> On Sep 16, 2022, at 4:25 AM, Michael Ströder <michael=[e-mail]> wrote:
> 
> Disclaimer: I don't consider myself a HR system expert.
> 
>> On 9/16/22 06:54, Danny Zollner wrote:
>> Creating a set of schemas for those that consume HR data would help
>> with the problem of sending HR-related data to other systems
> IMHO this is feasible.
> 
>> but doesn’t solve the problem I described.
> You're aiming at defining a SCIM schema for exchanging full HR data between HR systems of different vendors? I'm pretty sure none of the vendors are interested in that.
> 
>> I took the name “Worker” from the implementations of some of the most prominent HR systems. A worker is typically a higher-level classification that represents full-time employees, contractors, interns, and other types of workers.
> 
> This still sounds quite person-centric.
> 
>> The status of the employment is defined in an attribute on the object.
> > [..]
>> Specific to data security concerns regarding an HR schema, I think input is needed from players in the HR/HCM industry on if it would be wise to include extremely sensitive information such as salaries and social security numbers in a worker resource.
> 
> While AFAIK social security numbers are assigned to natural persons other HR data is bound to contracts. And in a HR system a natural person can have multiple contracts. So you would also have to model that.
> 
> Coming from the IAM world I often consume HR data and the "person" objects I derive from that have attributes which indeed rather represent a contract (employee number, status, time-span). And then I bind the user accounts to these person contract objects.
> 
> Ciao, Michael.
> 
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim