CODEWITHSUNDEEP
javasingle-sign-oncas
leopal
leopal

Reputation: 4959

Acceptable Usage policy issue with delegate authentication

We have configured both features stated in the title based on the official docs(aup & delegate authentication.

We use delagate authentication to intergrate with an external saml idp provider. So we have two means of authentication. The idp authentication and the local one(cas internal database authenticator).

After external and internal authentication we need to show the acceptance usage policy view when a condition A is met.

The above works as intended for local login, however, when authentication is performed in the external idp the acceptable usage policy page is not shown even if the condition A is met and the user eventually logs in the initially requested service.

Question: Why is this happening and are there any possible workarounds?

Cas server version: 5.3.7

Upvotes: 0

Views: 103

Answers (1)

Misagh Moayyed
Misagh Moayyed

Reputation: 4318

If you examine this block, you will find that verification of policy usage is linked to and created as an entry action of the STATE_ID_CREATE_TICKET_GRANTING_TICKET:

final ActionState ticketCreateState = getState(flow, CasWebflowConstants.STATE_ID_CREATE_TICKET_GRANTING_TICKET, ActionState.class);
ticketCreateState.getEntryActionList().add(createEvaluateAction("acceptableUsagePolicyVerifyAction"));
createTransitionForState(ticketCreateState, AcceptableUsagePolicyVerifyAction.EVENT_ID_MUST_ACCEPT, VIEW_ID_ACCEPTABLE_USAGE_POLICY_VIEW);

This is a limitation of the AUP flow such that the result of the verify action is sort of ignored and it's not taken into account to trigger the final view, even if it indicates so, in the delegation use case specially.

The 6.0.x branch changes this logic a bit to improve this behavior:

val ticketCreateState = getState(flow, CasWebflowConstants.STATE_ID_CREATE_TICKET_GRANTING_TICKET, ActionState.class);
createEvaluateActionForExistingActionState(flow, ticketCreateState.getId(), AUP_VERIFY_ACTION);
createTransitionForState(ticketCreateState, CasWebflowConstants.TRANSITION_ID_AUP_MUST_ACCEPT, VIEW_ID_ACCEPTABLE_USAGE_POLICY_VIEW);

You're welcome to experiment with the same approach in your 5.3.x deployment and report back. Be sure to test both cases thoroughly. If things work as expected, please post back and you can then post a pull request to the project to change/fix this behavior.

PS Note that that the entanglement of various webflow actions and states is something very tricky, as there are many modules that wish to insert themselves into the right webflow state to accommodate some behavior. Such modules generally know nothing about each other, and attempt to augment the flow somewhat agnostically. In these situations, chaining such things together can quite tricky.

Upvotes: 1

Related Questions