Use new laravel SCIM server

[uberbrady]

This isn't done yet. But it's an attempt to pull us up to a newer version of the laravel-scim-server library - or, at least, our fork of it, which is modified to provider slightly better logging.

It includes Group support. It will dynamically create groups according to which groups you have assigned to you as the service-provider side. Those groups inherently will have no permissions; the administrator needs to associate whichever permissions they want to whatever groups that are dynamically created. I'm not sure what will happen if the SCIM client (the Identity Provider) tries to assign a currently-existing group to a user - I imagine it will just grab that group by name and assign it.

I've been able to re-add Manager support. And it will understand Azure/Entra ID's messed-up violates-the-spec version of it. As well as standards-compliant versions of it, once that's implemented (it hasn't been, yet).

I've implemented Location and Company support as well. These have to be mapped to custom SCIM attributes -

• urn:ietf:params:scim:schemas:extension:grokability:2.0:User:location
• urn:ietf:params:scim:schemas:extension:grokability:2.0:User:company

These will actually create locations and companies if they don't exist. If you don't want that behavior, don't map those attributes.

I've tested it pretty heavily against Entra ID, but I need to keep testing it there, as well as a few other providers before it's ready for the world. Also some functionality still needs to be fleshed out and/or cleaned up.

But, it's progress.

[uberbrady]

This is closer now - there are plenty of FIXME's still to be addressed, and TODO's to be ignored, but the basic functionality is all there. It's able to sync managers, groups, Locations, and Companies from Entra ID and Okta (though Okta's implementation of Manager is....strange).

We'll need to get the FIXME's handled here, and over on the laravel-scim-server side. And, for pushing to master we will probably have to make a change to which branch is referenced in the composer.json.

And it looks like there's some conflicts I'll probably want to get resolved, so let me do that now.

[uberbrady]

(Fixed the conflicts in the composer files)

One question that we're still a little nervous about is the Group handling - if someone is listed as a member of an Administrators group in your IdP, but you don't want that to make them automatically Administrators in Snipe-IT - what do you do?

One argument you can make is an Administrator is an Administrator, so this shouldn't matter. And if you really want to have "Asset Administrators" - make that as a Group either in your IdP or just locally within Snipe-IT and assign it there?

But I'm not sure that that answer is the right way to think about it.

[StephenCourtney-CEGA]

(Fixed the conflicts in the composer files)

One question that we're still a little nervous about is the Group handling - if someone is listed as a member of an Administrators group in your IdP, but you don't want that to make them automatically Administrators in Snipe-IT - what do you do?

One argument you can make is an Administrator is an Administrator, so this shouldn't matter. And if you really want to have "Asset Administrators" - make that as a Group either in your IdP or just locally within Snipe-IT and assign it there?

But I'm not sure that that answer is the right way to think about it.

It feels to me that a suitable warning in the config interface would be enough for this? After all, if you're using an IdP and have Administrator groups setup, surely the onus is on you to be responsible and check the memberships are appropriate before setting up SCIM?

[snipe]

@StephenCourtney-CEGA Well, we don't really have a config page for SCIM (and we kinda like it that way). @uberbrady and I have been tossing this one around for a while and it just makes me really nervous. Not because the tech is bad, but because of what people could accidentally and unintentionally end up doing. It would be a very easy thing to not realize you were doing. Syncing groups sounds like something people would want to do by default, but because our permission groups don't necessarily map to one's directory permissions, I'm just afraid that people won't realize that mapping those might lead to unintended consequences. Yes, we'd add that to the docs, but we've found that people often don't read the docs, and we don't want to cause a security incident just because someone was in too much of a hurry to bother.

@uberbrady - Maybe a setting on the groups section, or something in the general settings? It would force it to be a deliberate choice so if something goes horribly wrong, it was at least a deliberate accident as opposed to something someone overlooked.

[codacy-production]

Not up to standards ⛔

_{TIP This summary will be updated as you push new changes. Give us feedback}