Matt, There are two steps in the surrogate process. 1. check attributes of primary [admin] to see if they can preform the surrogate operation (e.g. admin in accounting can only surrogate as an accounting employee, not marketing employee) 2. release surrogate id [test] and surrogate attributes to application [groovy script] (i.e. as far as application is concerned, it only ever knows about surrogate, and nothing about admin)
Cas suggests that the surrogate process be used for trouble shooting. I can see it being useful for secondary or role based accounts where multiple people may have access to the same application (e.g. all front office staff have access to the email account i...@company.com<mailto:i...@company.com>, so would log in as info+employeeId, - I do know there are other ways to do this). The audit system would record when when a surrogate operation occurred for an application. But the application would have no way to know which principal was doing the impersonation. Perhaps it is possible to add a groovy script to cas that would create an attribute(s) containing the properties of the primary. https://apereo.github.io/cas/6.6.x/integration/Attribute-Resolution-Groovy.html Ray On Thu, 2023-05-04 at 12:32 -0400, mailing_lists....@melson.fastmail.net wrote: Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information. (CAS 6.6.x) The documentation suggests that in the SurrogatedRegisteredServiceAccessStrategies that the attributes/principal being evaluated is the "primary" user (Specifically it says: "Decide whether the primary user is tagged with enough attributes and entitlements to allow impersonation to execute" and the example attribute is a givenName of "Administrator"), which I understood to be the person doing the impersonating (aka, "admin" in the test+admin construction). However, in my tests of both the Groovy and Attribute flavors of the strategy, the attributes and principals being evaluated are those of the account being impersonated ("test" in the test+admin construction). I've reproduced this in a very trimmed down environment, so I don't think it's a quirk of my config. Which account's attributes are supposed to be evaluated and/or exposed to the groovy script? And if it is meant to be the surrogate, are there any hints on how to resolve attributes for the primary account for use in the groovy script strategy - it'd be helpful in my environment if we could make access decisions based on the primary account's attributes. Thanks in advance, Matt -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org<mailto:cas-user+unsubscr...@apereo.org>. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/d4b2a428-39d3-944b-d079-0a5e1ae66383%40fastmail.net. -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/4bff23bf8a8d50c0aba1b9265fbda6736c426ccc.camel%40uvic.ca.
