ActionExecutionException when surrogate-webflow enabled and returning attributes

513 views
Skip to first unread message

Richard Schneider

unread,
Oct 16, 2019, 8:57:00 AM10/16/19
to CAS Community
Hello!

We're on 6.1.0-RC6, and working on enabling surrogate authentication. However, we're getting the following error when authenticating (after submitting credentials):

ERROR [org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet]] - <Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.webflow.execution.ActionExecutionException: Exception thrown executing org.apereo.cas.web.flow.action.SurrogateAuthorizationAction@69f3e556 in state 'generateServiceTicket' of flow 'login' -- action execution attributes were 'map[[empty]]'] with root cause>


This error occurs whether or not surrogate authentication is being attempted. However, it only occurs when org.apereo.cas:cas-server-support-surrogate-webflow is compiled in. Removing that dependency while changing no other configuration will cause it to work (albeit without surrogate authentication capabilities).

After some testing, we've determined this occurs when logging into specific services with a mapped attribute policy. If the attribute mapping (specifically, the USER_ID line in the service configuration) is removed, the authentication flow works (although the service application, which needs that attribute, does not).

The other interesting thing is that if, after receiving the error message, you trigger another SSO event to the service, it works fine. So maybe it has something to do with CAS having trouble initially fetching the attributes?

Thanks for any help!

cas.properties:
cas.server.name=https://cas.example.com
cas.server.prefix=${cas.server.name}

logging.config: file:/etc/cas/config/log4j2.xml

# Disable CAS default 'casuser' user
cas.authn.accept.users=

# Embedded server
server.port=8080
server.servlet.context-path=/
server.ssl.enabled=false

# LDAP
cas.authn.ldap[0].ldapUrl=ldaps://ldap.example.com
cas.authn.ldap[0].bindDn=redacted
cas.authn.ldap[0].bindCredential=redacted
cas.authn.ldap[0].searchFilter=sAMAccountName={user}
cas.authn.ldap[0].type=AD
cas.authn.ldap[0].baseDn=ou=users,dc=example,dc=com
cas.authn.ldap[0].dnFormat=cn=%s,ou=users,dc=example,dc=com
cas.authn.ldap[0].principalAttributeList=memberOf,name,sAMAccountName
cas.authn.ldap[0].principalAttributeId=sAMAccountName

cas.authn.file.separator=::
cas.authn.file.filename=file:///tmp/passwords

# Service registry
cas.serviceRegistry.json.location=file:/etc/cas/services/


cas.authn.surrogate.separator=+
cas.authn.surrogate.principal.principalAttribute=sAMAccountName,name
cas.authn.surrogate.ldap.ldapUrl=ldaps://ldap.example.com
cas.authn.surrogate.ldap.bindDn=redacted
cas.authn.surrogate.ldap.bindCredential=redacted
cas.authn.surrogate.ldap.searchFilter=sAMAccountName={user}
cas.authn.surrogate.ldap.baseDn=ou=users,dc=example,dc=com
cas.authn.surrogate.ldap.memberAttributeName=memberOf
cas.authn.surrogate.ldap.surrogateSearchFilter=(&(cn={user})(cn=admin_username))

cas.authn.attributeRepository.ldap[0].attributes.name=name

cas.authn.attributeRepository.ldap[0].ldapUrl=ldaps://ldap.example.com
cas.authn.attributeRepository.ldap[0].bindDn=redacted
cas.authn.attributeRepository.ldap[0].bindCredential=redacted
cas.authn.attributeRepository.ldap[0].searchFilter=sAMAccountName={user}
cas.authn.attributeRepository.ldap[0].baseDn=ou=users,dc=example,dc=com
cas.authn.attributeRepository.ldap[0].searchFilter=cn={user}

cas.authn.attributeRepository.ldap[0].attributes=memberOf,name,sAMAccountName

cas.authn.samlIdp.entityId=https://cas.example.com/idp
cas.authn.samlIdp.scope=example.com

Configuration for service throwing the error:

{
    "@class": "org.apereo.cas.services.RegexRegisteredService",
    "serviceId": "https://[^/]*\\.example\\.com(:[0-9]+)?(/.*)?",
    "name": "Example Service,
    "id": 12586,
    "evaluationOrder": 100,
      "attributeReleasePolicy": {
        "@class" : "org.apereo.cas.services.ReturnMappedAttributeReleasePolicy",
        "allowedAttributes": {
          "@class" : "java.util.TreeMap",
          "name": "USER_ID"
        }
      }
}


Richard Schneider

unread,
Oct 17, 2019, 2:48:09 PM10/17/19
to CAS Community
I ended up solving this issue with a workaround. Instead of using a ReturnMappedAttributeReleasePolicy in the service configuration, I used a GroovyScriptAttributeReleasePolicy with a script that basically does the same thing:

"attributeReleasePolicy": {
  "@class" : "org.apereo.cas.services.GroovyScriptAttributeReleasePolicy", 
  "groovyScript" : "/etc/cas/scripts/user_id_release.groovy"
}

import java.util.*

def Map<String, List<Object>> run(final Object... args) {
    def currentAttributes = args[0]
    return [USER_ID: currentAttributes["name"]]
}

Since that change is all that was needed to fix the problem, I'm wondering if there's some bug in the interaction between surrogate authentication and ReturnMappedAttributeReleasePolicy.
Reply all
Reply to author
Forward
0 new messages