Many weeks ago I blogged about how I could no longer add images to blogs and this was preventing me from publishing some entries I had which needed screen shots...

We have since fixed that issue, but I'm not sure I shared what happened.

As it turns out, on liferay.dev we were following security best practices by creating and configuring a Role with necessary permissions, we were assigning the Role(s) to new or existing User Group(s), and then we would add User(s) to the User Group(s) so they would have the access they needed.

After an upgrade, users were suddenly unable to do things, for example, I couldn't upload blog images any longer.

We were stumped trying to figure out what had happened in the upgrade. Did the database upgrade corrupt the permissions tables? Did the upgrade include a new bug or something?

It ended up being none of these things, it was caused by a new feature added to SAML to support using SAML response attributes for User Group assignments. Or, when no such attributes were defined, User Group memberships were removed.

And so, yeah. I was assigned to the User Group that would allow me to upload blog images, but since we were not managing User Group membership via SAML attributes (why would we do that, we don't want to manage every Liferay aspect in SAML when we don't need to), as soon as I would log in, my User Group memberships was being removed because the SAML attributes weren't there and I would no longer have the permissions I needed.

This didn't stem from a bug, it actually stemmed from a ticket to add support to SAML for User Group management; we had it for LDAP, we had it for OpenID Connect, but we didn't have it for SAML, and so it was implemented. This of course would allow an organization to centrally manage users and group membership and is generally also considered a best practice.

At liferay.dev though we were kind of stuck in this grey area. You see, Liferay uses Okta for the IdP and that fronts all of the Liferay systems, the public ones as well as the internal ones used by Liferay employees. And in this landscape, liferay.dev is a tiny player. We're at the bottom of everyone's priority list. That's okay, though, even at the bottom we get the support we need.

None the less, it is often still easier for us to solve some things on our own. Like User Group membership. Why create the groups in Okta and assign the memberships there and pass them as SAML attributes when those groups are only going to be used on one SAML SP out of many?

So yeah, we had been creating the User Groups in our own instance and managing memberships ourselves rather than managing them in Okta.

And that's why we started breaking after the upgrade. The upgrade included using SAML for User Group management, which we weren't doing, and was clearing all of the group memberships.

Why Am I Going Into All of This?

Well, I'm giving the background that, quite possibly, some of you have hit or will hit if you too are using SAML but not for group management.

So yeah, this is kind of a heads-up notification.

And also I'm providing a recommendation:

SCIM support is behind a Beta feature flag in 2024Q1 through 2024Q3, it will move to a Release feature flag in 2024Q4, and it will be an official part of 2025Q1 (meaning no more feature flags).

Even though it is currently behind a Beta feature flag, I've been assured by the Liferay team that owns the SCIM feature that any reported bugs will be resolved, so it is okay to use this feature in production.

What the Heck is SCIM?

I'm not going to go into a great deal of explanation here because Liferay has already provided an introduction to SCIM as well as its User and Group APIs.

SCIM stands for System for Cross-Domain Identity Management, and it's an open standard backed by RFCs to handle user and group provisioning.

Using SCIM is intended to get away from some of the complexities that you may run into such as different SAML platforms using different attributes, etc for managing these aspects.

A bigger question, of course, is whether you can use SCIM in your environment.

I asked Gemini what systems support SCIM, and it gave me the (hopefully accurate) response:

Here are some systems that support SCIM: 

• Azure AD: Has supported SCIM since 2016 and can be used to provision accounts and groups to multiple systems, including Amazon Web Services. 
• Okta: A SCIM-based directory service that can be integrated with StrongDM. 
• Google: A SCIM-based directory service that can be integrated with StrongDM. 
• OneLogin: An identity provider that supports SCIM provisioning with Contentstack. 
• FusionAuth: A CIAM system that works well with SCIM. 
• PingOne: A commercial solution that offers built-in support for SCIM provisioning. 
• PingFederate: A commercial solution that offers built-in support for SCIM provisioning. 
• WorkOS: A SCIM provider that offers end-to-end support for user management, enterprise SSO, and audit logs. 

SCIM, or System for Cross-domain Identity Management, is a standard that automates the exchange of user identity information between IT systems. It uses a REST API with JSON or XML data formatting.

I said "hopefully accurate" because I just assume that a) this list is likely incomplete and b) this list might include an entry that shouldn't be there.

Whatever IdP you're using, though, you should be able to find out if it supports SCIM and, if it does, I'd encourage you to enable and use it's SCIM support.

And, of course, if you encounter problems with SCIM, open a support ticket or drop a message in the Liferay Community Slack and we'll work to get it resolved...