Question about SurrogateRegisteredServiceAccessStrategies

[mailing_...@melson.fastmail.net]

(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

[Ray Bon]

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 in...@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_...@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.

--

- 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+u...@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.

[mailing_...@melson.fastmail.net]

On 5/4/23 3:31 PM, Ray Bon wrote:
> 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)

So just to clarify, that means when the documentation here:

https://apereo.github.io/cas/6.6.x/authentication/Surrogate-Authentication-AccessStrategy.html

states

"Additionally, you may on a per-service level define whether an
application is authorized to leverage surrogate authentication." it's
auctually just referring to controlling what attributes from the
surrogate are released to the service? (Which is a way of denying, so I
can see it).

Remain slightly perplexed however, because the documentation says:

"Decide whether the primary user is tagged with enough attributes and

entitlements to allow impersonation to execute," but it sounds like it's
expected that the primary user and their attribute plays no role.

I've got the feature working fine, the hope was to just say that user X
could only impersonate user Y for certain services, and the
documentation seemed to suggest these RegisteredServiceAccessStrategies
were the methods for doing so.

In any case, I'll go look to see if there's a way to copy over some
attributes from the principal to the surrogate via the method you suggested.

Matt

[Ray Bon]

Matt,

There is a separation between the sessions [and capabilities] that exist on the cas side and the service side.

What you are trying to do is mix the two.

The quote, 

"Decide whether the primary user is tagged with enough attributes and

entitlements to allow impersonation to execute,"

is referring to the cas decision to allow the primary to act as a surrogate. It has nothing to do with the service nor any decisions the service should make. In fact, the whole point of the surrogate feature is that the service has no knowledge of who actually performed the log in process.

Many of the features of cas can be applied globally or on a per service basis. That includes surrogacy and attribute release. Cas is also capable of performing some coarse grained authorization; either for the service, or in your case, for surrogacy.

Also note that there are multiple steps in the 'log in' process. (Determined by enabled cas features/config and service config.) Each step can be affected by previous steps, and affect subsequent steps. 

So a 'normal' log in might look like:

authn -> get attributes for user -> select attributes to release -> redirect user and selected attributes to service

A surrogate authentication might be:

authn -> get attributes for primary -> check if primary can act as surrogate -> get surrogate -> get attributes for surrogate -> select [surrogate] attributes to release -> redirect surrogate and selected [surrogate] attributes to service

What are you trying to accomplish by releasing both surrogate and primary attributes to a service?

There may be a better/alternative approach.

Ray

On Thu, 2023-05-04 at 16:08 -0400, mailing_...@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.

--

- 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+u...@apereo.org.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/67bed492-8e0c-07c6-ca0f-0dfbbeec986c%40fastmail.net.