nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How is the remote address in Crowd's ValidationFactor enforced?

Alexander Benschop

I am currently working on implementing Crowd via Spring Security. I am using the Crowd Integration API v2.4.2 for this purpose. To enforce users are authenticated, I am using the CrowdSSOAuthenticationProcessingFilter for this matter. The authentication is unfortunately not succesful when I try it from my local machine, after some debugging I've noticed that this is caused by the enforcement of ValidationFactors.

The only ValidationFactor I have at this moment is the remote address, which is 0:0:0:0:0:0:0:1 (ipv6 loopback). I have tried to add this address to the allowed remote addresses in Crowd, as well as editing it to 127.0.0.1 or another address that was already allowed in the Crowd configuration. Changing the value to an empty string does result in succes though. I can't really find out how this is enforced, maybe I'm missing some configuration. A hint in the right direction would very much be appreciated.

Thanks,
Sander Benschop

Accepted answers

joe

Crowd should check the ValidationFactors against those provided when the session was created. If token validation only succeeds when the empty string is passed for a remote address then that suggests that the session was created without the application passing in a remote address.

If both of these applications are under your control then you'll need to look into the difference in behaviour.

All comments

joe

The ValidationFactor is there to ensure that a session is being used by the same end user that created it, to prevent hijack. The CrowdSSOAuthenticationprocessingFilter will populate it with the client IP address before passing the details to Crowd to ensure a match, but it shouldn't prevent creation of a session. However, if one SSO application provides a different IP address when it authenticates the session then it will fail.

Are you configuring a single application here or getting SSO working between applications? Can you provide more details about authentication failing?

Alexander Benschop

Joseph, I am trying to get SSO working between applications.

The CacheAwareAuthenticationManager's isAuthenticated method is called, to which the token and validation factors are passed. Subsequently the SecurityServerClientImpl's isValidToken function is invoked via an Xfire proxy. This function returns false if the remote address is something other than an empty string.

joe

If both of these applications are under your control then you'll need to look into the difference in behaviour.

Alexander Benschop

Thanks, your comment put me in the right direction. I was using a custom controller which spoke with the Crowd authentication provider to return a Crowd SSO token for the initial authentication. I did not provide it with the remote address though, which caused an inconsistency later on.

judy4

I am having the same issue as above but my application is coded using php and the class that is doing all the magic directed me to this page.

How can I solve this issue since the token is the same from one of our applications using crowd but my custom php application is returning Crowd SSO inconsistency: validation factors failed for token XXXXXXXXXXXXXXX - malfeasance?

Note:I dont have rights to the crowd console but only the administrator.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

crowd

java

validation

spring

crowd-integration