Hi, Please allow me to take the conversation up one level. A typical use case is to put COmanage behind SATOSA since it is one of the SPs/services. But you want to treat the COmanage SP differently than the other SPs. For the other SPs you want SATOSA to find the primary identifier from the assertion/attributes sent by the campus IdP, then use it to look up the user in an attribute authority (usually LDAP), find attributes like givenName, sn, and email and add those attributes in the assertion sent to the SP. The reason is that the attributes managed by the VO through COmanage are usually what should be sent to those downstream SPs. The primary identifier used to lookup the user in the attribute authority (LDAP) is usually the ePPN, ePTID, ePUID, and so on. For the COmanage SP, however, you want to find the primary identifier, but not have it do any lookup in LDAP. Instead you want to have COmanage receive the primary identifier(s) so it can provision it/them to the directory (ie. LDAP). You might be tempted to have ePPN/ePTID/ePUID sent to the COmanage SP by just passing it through. But I would not do that. The primary reason is the scoping issue you are seeing. Instead of just passing through ePPN/ePTID/ePUID I would configure SATOSA for the COmanage SP (with an override) to put ePPN/ePTID/ePUID into a different SAML attribute, one that is not scoped. A good choice would be one based on the "new" attributes defined in voPerson, but you can use whichever SAML attribute you like. You just need to coordinate it between SATOSA and the COmanage SP. Then configure the COmanage SP to consume it and configure the COmanage Organizational Identity EnvSource to consume it from the environment. Then the Organizational Identity in COmanage will have the identifier(s) as asserted by the campus, but you will have avoided "messing around" with the scope. If I did not anticipate your use case and you really need to have ePPN/ePTID,ePUID passed through as scoped attributes, then my apologies... Thanks, Scott