SAML group assertions not working & no logging.

[SynoUser-NL]

Current Behavior

After updating our Self-hosted Flowfuse to V2.7.1, I enabled the "Manage roles using group assertions" option in SSO settings, with Team Scope defined as Apply to all teams. In our tests with access to a Team, we found that adding an AD account to a "coupled" AD group \ role did not give the account access to the Team\Instance. Neither were we able to find any logging on SSO issues in the Flowfuse docker loggings. Our AD\EntraID admin was also unable to see any information that may help in resolving this issue.

The same also applies to the Admin Users SAML group name: accounts added there to not give admin access to Flowfuse.

This leaves us with a Flowfuse environment that we cannot manage by AD groups, which is how Flowfuse is configured now. Fortunately, local rights assignment is working.

In the above config we have the following questions:

• How can we see what's going on with SSO when logging in and where errors possibly occur?
• What happens when an AD role group (for example, the Dashboard role group) is empty?
• What happens when a Team has no corresponding AD role groups?
• When a user\account has different rights in SSO from local, which rights have preference?

Can we please get short-term help to get more info on what's happening in Flowfuse and\or get this working?

PS: I am hesitant to disable or change the SSO settings (without VM snaphot) because last time we did this it resulted in user database issues. PPS: It's very possible that we're doing something wrong, but with no logging information there is no starting point.

Expected Behavior

Adding an account to an AD role group gives access to that Team \ Instance in the configured role.

Steps To Reproduce

As described above.

Environment

• FlowFuse version: 2.7.1 (self-hosted)

Have you provided an initial effort estimate for this issue?

I am not a FlowFuse team member

[knolleary]

@SynoUser-NL happy to get on a call today to screenshare on this

[SynoUser-NL]

Thanks for your quick reply! Let me see when the people who I think are needed for this are available, and I'll plan asap.

[knolleary]

Some notes in prep for our call.

We may need to add some additional debug to understand what is being returned by AD and why it isn't being acted on.

This will involve:

1. opening a shell in the forge container: docker exec -it flowfuse_forge_1 /bin/sh
2. editing /usr/src/forge/app/node_modules/@flowfuse/flowfuse/forge/ee/routes/sso/auth.js
3. line 82 - add console.log(samlUser)
4. exit shell
5. restart container: docker restart flowfuse_forge_1

We'll step through this together on the call.

[SynoUser-NL]

Hi @knolleary and @hardillb ,

Thanks for your quick help on this! As I was shure I tested this and was a bit stunned things were working, I was thinking.. It occurred to me that the one thing we did do now was restart the Flowfuse instance. We did not do this after changing the SSO settings, and I think that may have been the issue. Although this is not mentioned in the documentation I guess it makes sense to restart FF after SSO\SAML changes.

Thanks again for your quick help!!

[knolleary]

To summarise, I believe this was all working as intended - although it does reveal a couple opportunities to improve the UX.

A restart of the platform is not necessary to apply SSO config changes.

For the current behaviour, there are some points we need to clarify in the docs:

1. group membership is only applied when a user logs in; changes made to a user's group memberships on the SAML provider will not get applied until they next login.
2. changes made to a team membership within the platform do not get applied back to the SAML provider; so changes will be reverted when they next login

Looking forwards, we can improve the behaviour in two ways (although not simple to do):

1. investigate if we can monitor/refresh user group membership with the SAML provider to be able to reflect changes without requiring a logout/in cycle.
2. disable team membership management if managed by SAML. This is hard as the SAML configuration applies to a user based on their email domain. If all users on the platform come from the same SAML provider (eg self-hosted), then it makes sense. It does not make sense for FFC where has a mixed user based.

[SynoUser-NL]

With regard to Disabling Team Membership Management when SAML is used: what happens when the SAML is failing? In the doc a fallback to local accounts (for admin access) is suggested. If you disable Team Membership Management completely when SAML is enabled we would not be able to have or manage local admin accounts. So if you decide to go that route, please make sure local admins can still be managed within FF. Also, the way it works now, if I understand correctly, I could give an existing user immediate (and temporary) access to a Team Role, which would automatically be "reset" when that user logs in again. Unless I add the user to the appropriate AD group. This is a nice feature to have imho.

One suggestion is to please make a setting in the FF SSO config to enable the log line. With that info we may not have had to call in your help. Which of course is immensely appreaciated! Again, thanks very much, both of you!

[hardillb]

If you disable SAML SSO (e.g. when it's not available), then users will keep the team memberships they had when they last logged in to the system as that is the sync point. This includes Admin access.

Audit log events are created each time a users groups are changed, but as we mentioned on the call we will look at adding more debug level logging.

[joepavitt]

Underlying issue was fixed, but need to improve logging to help self-service debugging