This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Sounds like something that would be better achieved with an SSO system where the account status is controlled in a single place.

Also, in your description, why do you need to authenticate as the user to the web service? This sounds more like a check by the app as to whether a user is allowed to authenticate, rather than something that should be done as the user themselves.

Comment

Hi Luke, An SSO solution would fit better but Im not able to push that kind of thing and have to make do with what's exposed to me.

To make it a little more clear
heres the flow

1. user provides - username and password via login page to Spring Security
2. The UserDetails service retrieves the locally stored username and password
3. The UserDetails service returns them spring security
4. Spring security checks the roles and permissions
5. A web service call is made with the username and password to check that the user is still "ok" within the company - the web service will return
user expired, account locked, password expired...
6. if both spring sec and the ws call are ok we let the user login

step 5 could happen after step 1?

bear in mind Im a spring security noob !

Mapp

Comment

Again, I can't see any reason for duplicating the same password information within the application and the company as a whole. How are they kept in sync? Why not just use the web service as the actual authentication mechanism, so that a user can't log in at all if they aren't supposed to?