User Attributes for MongoDB Authentication not found (5.1.0)

214 views
Skip to first unread message

Karl Banke

unread,
Jun 23, 2017, 4:48:34 AM6/23/17
to CAS Community
I enabled MongoDB Authentification as per the documentation.

1 ) I added the following to the POM

<
dependency>
<groupId>org.apereo.cas</groupId>
<artifactId>cas-server-support-mongo</artifactId>
<version>${cas.version}</version>
</dependency>

2) Included the following properties

#
# Mongo DB Authentication
#
cas.authn.mongo.mongoHostUri=mongodb://cas:*******@cas-mongo/cas-mongo-database
cas.authn.mongo.usernameAttribute=username
cas.authn.mongo.attributes=first_name,last_name
cas.authn.mongo.passwordAttribute=password
cas.authn.mongo.collectionName=users
#cas.authn.mongo.name=

# cas.authn.mongo.principalTransformation.suffix=
cas.authn.mongo.principalTransformation.caseConversion=NONE
# cas.authn.mongo.principalTransformation.prefix=

# cas.authn.mongo.passwordEncoder.type=NONE|DEFAULT|STANDARD|BCRYPT|SCRYPT|PBKDF2|com.example.CustomPasswordEncoder
cas.authn.mongo.passwordEncoder.type=DEFAULT
cas.authn.mongo.passwordEncoder.characterEncoding=UTF-8
cas.authn.mongo.passwordEncoder.encodingAlgorithm=SHA-256
# cas.authn.mongo.passwordEncoder.secret=

Server starts normally and User is authenticated. However, when I connect to /cas/status/ssosessions and expand the session of the logged in user, the principal attributes field is empty.
I would expect it to contain first_name and last_name as per the configuration and the data in the database.

The users collection in the database looks like this:

> db.users.find()

{ "_id" : ObjectId("594bc3c32d5c8c3cf244f3bb"), "username" : "casuser", "password" : "****", "first_name" : "Cas", "last_name" : "User" }

Also, if I comment out the cas.authn.mongo.attributes property, users can no longer be authenticated because of a NullPointerException.

Karl Banke

unread,
Jun 23, 2017, 4:54:23 AM6/23/17
to CAS Community
As I side note: There are also no attributes when using the attribute resolution at /cas/status/attrresolution.

Karl Banke

unread,
Jun 28, 2017, 11:27:37 AM6/28/17
to CAS Community
Now Using 5.2.0-RC1-SNAPSHOT for another reason. I debugged the login process.

- The profile is created in by the profile creator called from the MongoAuthenticationHandler that extends AbstractWrapperAuthenticationHandler
- As expected, the profile has two attributes last_name -> User, first_name -> Cas
- This is then passed to create a new DefaultHandlerResult in the AbstractPac4jAuthenticationHandler
- It then reaches the AbstractAuthenticationManager.authenticateAndResolvePrincipal as a Handler Result where the principal has the two attributes
  correctly set.
- Here the resolvePrincipal method is called with the following attributes:

handler:    MongoAuthenticationHandler
resolver:   org.apereo.cas.authentication.principal.resolvers.PersonDirectoryPrincipalResolver
credential: UsernamePasswordCredential
principal:  The aforementioned Principal

After this call, the principal has no attributes left.

Within the PersonDirectoryPrincipalResolver the method retrievePersonAttributes(principalId, credential) returns null, which makes sense, since there are none defined. The attribute list is obtained from the attributeRepository which is by default an instance of CachingPersonAttributeDaoImpl.
There the person with the given id has no attributes assigned, since the only way it could have been loaded is by the process that now tries to resolves the attributes. Is there any other place where I have to declare what the possible attributes are?! 

Misagh Moayyed

unread,
Jun 28, 2017, 11:53:39 AM6/28/17
to cas-...@apereo.org

You’re doing just fine. The mongo authN simply ignores the attributes as it assumed attributes are to be retrieved from separate attribute repository sources. Dima and I were just reviewing this actually,  and are working on a change to ensure attributes produced by the authentication process can be merged/echoed back with attributes produced by separate repository sources, if any. This behavior/feature only exists for a certain number of authN schemes, not for all…and our goal is to make sure it works for every mode of authN regardless.

 

This will be fixed before RC1 goes out.

 

--Misagh

--
- CAS gitter chatroom: https://gitter.im/apereo/cas
- CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html
- CAS documentation website: https://apereo.github.io/cas
- CAS project website: https://github.com/apereo/cas
---
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/06b86984-c0a6-4f81-a0e5-ae56bc0100d3%40apereo.org.

Reply all
Reply to author
Forward
0 new messages