Shibboleth auth's autocreate and sync functions both rely on the same //shibboleth/mapping block in koha-conf.xml. Because autocreate requires mapping and/or defaults for branchcode and categorycode, this has the undesired affect of overwriting manual edits to borrowers on later syncs if the those fields are not delivered via shibboleth and explicitly mapped. Example: 1) Patron signs in for first time and borrower account is autocreated with a default branch and categorycode. 2) Staff update patron to set new branch and category codes as needed (e.g. from "SSOAUTH" to "MAINLIB"). 3) On next sign-in, patron's mapped data is synced, but branch and category codes are overwritten with the defaults. Suggested workaround is to differentiate //shibboleth/autocreatemapping vs //shibboleth/syncmapping. This allows greater control over which fields are mapped for autocreate vs sync. This schema change would not be backward compatible, though.
At one point we had autocreate and sync both working for our use case, but since some Koha upgrade, possibly 23.05, it stopped working the way that we expected it to and have had to turn off sync. In our use case we are using SSO for library staff accounts. We had autocreate set some default level of permissions so that staff could login to the staff interface and do some basic circ when they first logged in. Then we managed elevating permissions in Koha. We had sync turned on and our SAML so that we could update staff attributes like branchcode and name in the IdP and the Koha account would update the next time the staff logged in. Originally the sync allowed for updating the user's attributes sent by SAML, but allowed for the elevated permissions to be retained. We had to turn off sync because Shibboleth started syncing the permission flags to the default and all staff lost their permissions. We don't store and send permission flags in our IdP, but to get this working again without a patch we would have to do that. I think Shibboleth's sync should only update attributes that are explicitly passed from the SAML app, so that you could configure defaults for other fields in autocreate. This is particularly useful for setting default permissions for new staff.