evaluationOrder bug?

[Baron Fujimoto]

I may have encountered a bug in CAS 5.0.10 for the evaluationOrder parameter in service registrations.

Registrations have an evaluationOrder parameter that sets precedence when you have more than one matching registration. We've handled cases like this by appending some zeros to the evaluationOrder value for the more general/default case (ex. https://example.edu). Therefore its evaluationOrder is > than the evaluationOrder of the more specific case like https://example.edu/foo.

Example registrations:

{
"name" : "GeneralNoAttr",
"serviceId" : "^https://example\\.edu(/.*)*",
"description" : "General no-attribute registration",
"id" : 20180508174231,
"evaluationOrder" : 200002230000,
"attributeReleasePolicy" : {
"@class" : "org.apereo.cas.services.DenyAllAttributeReleasePolicy"
}
"@class" : "org.apereo.cas.services.RegexRegisteredService",
}

{
"name" : "MoreSpecificAttr",
"serviceId" : "^https://example\\.edu/foo(/.*)*",
"description" : "Specific attribute-enabled registration",
"id" : 20181022144024,
"evaluationOrder" : 20000233,
"@class" : "org.apereo.cas.services.RegexRegisteredService",
}

I was troubleshooting an application that was not receiving attributes as expected (invoking DenyAllAttributeReleasePolicy of the more general registration[*]) when I discovered there appears to be some limit to this.

While setting things up for a new /foo registration, the more general registration's evaluationOrder got 4 0s appended. That's when things broke, and all the more specific registrations (e.g. /foo, /bar, etc) stopped returning attributes. On a hunch, I amended the more general evaluationOrder to only have 2 0s appended (known to have worked previously). Things started working again as expected.

It almost seems like an overflow bug, where the evaluationOrder wrapped or something.

[*] Is there a way to tell which service registration is is actually matching? Our DEBUG logs don't seem to show this, but perhaps it's just not enabled in the logging config? This would facilitate troubleshooting these types of issues.

--
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

[Andy Ng]

Hi Baron,

Looking at the source code, you can see that evaluationOrder is only an integer
https://github.com/apereo/cas/blob/v5.0.10/core/cas-server-core-services/src/main/java/org/apereo/cas/services/AbstractRegisteredService.java#L77

And for Java, integer have a limit to it (A quick google search show me "2,147,483,647", should be similar)

So I think your assumption of int overflowing is correct. If you add 0 to your service, you can only have ~10 services.

I think you need to either:
- not adding 0 to sort out the ordering
- Change the evaluationOrder to use BigInteger instead, which requires some coding to do, but is not impossible, BigInteger pretty much don't have maximum, so add as many 0 as you like (but the performance might be downgraded of course)

Cheers!

- Andy