Force lower case on principal username returned to application

[HURTEVENT VINCENT]

Hello,

We upgraded our CAS server from 3.5.2 to 4.2.6 and we observe a difference in the way the principal username is returned to CASsified app.

Before, I think that CAS returned the username as it was typed in the login form by the user. But now, CAS returns the username (SAMAccountName in our case) as it has been created in our directory.

For some reasons, our SAMAccountName are mixed cased, and the applications which don’t force the case on the username they get from CAS, don’t do the matching between the username and their user table.

Is there a way to lower case the username as it will be sent to applications ?

I’ve found PrincipalNameTransformer but it’s between the username typed in the form and the authenticationHandler.

GroovyPersonAttributeDao could be a way to this ? Have you got some documentation about it ?

Thank you

[Emilian Mitocariu]

I would also be interested if this is possible, my CAS version is 5.1

[Christian Axel Schmidt Dick]

at the json service: https://apereo.github.io/cas/5.1.x/integration/Attribute-Release-PrincipalId.html

"usernameAttributeProvider": {
  "@class": "org.apereo.cas.services.DefaultRegisteredServiceUsernameProvider",
  "canonicalizationMode": "LOWER",
  "encryptUsername": false
},

[Emilian Mitocariu]

I tried to add that to the json file for my service definition and when I try to login it says that the application is not authorized to use CAS. Is something missing me?

[Christian Axel Schmidt Dick]

can you share your json file? something must be wrong there

El mar., 17 oct. 2017 a las 15:33, Emilian Mitocariu (<mitocari...@gmail.com>) escribió:

I tried to add that to the json file for my service definition and when I try to login it says that the application is not authorized to use CAS. Is something missing me?

--
- 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/42cf06cb-eb6c-4212-9cc2-908b3a5f86c3%40apereo.org.

--

Christian Axel Schmidt Dick about.me/schmidtchristian

[Ray Bon]

Emilian,

Check your service id. Even though it is a regex, it can still picky. A trailing slash in the id (.*com/.*) is enough to prevent a match if the client does not send the '/'.

Ray

On Tue, 2017-10-17 at 06:33 -0700, Emilian Mitocariu wrote:

I tried to add that to the json file for my service definition and when I try to login it says that the application is not authorized to use CAS. Is something missing me?

-- 
Ray Bon
Programmer analyst
Development Services, University Systems
2507218831 | CLE 019 | rb...@uvic.ca

[Emilian Mitocariu]

I can't post my json file as I'm home right now and it is on a test VM at work. But the thing is that it worked before adding

"usernameAttributeProvider": {
  "@class": "org.apereo.cas.services.DefaultRegisteredServiceUsernameProvider",
  "canonicalizationMode": "LOWER",
  "encryptUsername": false
},

to the json file. It's either because of the above code or maybe I unintentionally modified something else in the file (I'll check for typos tomorrow).

[Emilian Mitocariu]

Turns out my test VM was a little older and had CAS 5.0.5 that doesn't support "canonicalizationMode", only my production server has CAS 5.1. I updated CAS to 5.1 and now it works.

Thanks for the help guys.