• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

JSF logs in as another user after failed attempt at secure resource with Security API

 
Ranch Hand
Posts: 109
1
Netbeans IDE Chrome Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi folks! I'm building an EE8 app and am using the new Security API with JSF. I have an issue with authorization and am not quite sure if it's mostly JSF-related or Security-related.

I'm using a custom IdentityStore to query the database against the provided email and password. Of course the users are categorized by roles (admin, moderator, user for example) and each of these roles have their secured resources declared in web.xml.

The whole auth process works beautifully if done correctly, the user logs in, if tries to access other role resource WildFly blocks him, if unauthorized user tries to access WildFly again blocks them... Logout works nicely as well...

But when a user tries to access another resource and gets blockes if they go back (in the browser) and put their credentials, they'll log in as another user.

The issue happens like this when I'm testing:
1. log in as admin
2. try to access moderator resources
3. WildFly throws forbidden
4. go back in browser and logout
5. try to access moderator resources
6. my code sends you back to login.xhtml
7. put user credentials
8. tries to redirect you to the moderator resource
9. go back in browser
10. put admin credentials
11. you are logged in as moderator

I'm thinking that at some point (perhaps when WildFly throws the Forbidden page and I press back) I'm not invalidating the session or not emptying the email and password fields correctly. Since it tries to redirect you to the forbidden resource after you've put wrong credentials I guess JSF is keeping something in the session right?

I'm posting this and coming back to post some code.
 
Vasilis Souvatzis
Ranch Hand
Posts: 109
1
Netbeans IDE Chrome Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Enabling the custom form authentication with JSF2.3


LoginBackingBean.java


IdentityStore.java (some code ommited)


I tried nullifying the user and password in the @PostConstruct of LoginBackingBean in case that was what kept the values but it's not.
 
Bartender
Posts: 20842
125
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I haven't looked at that stuff yet, but I very much doubt that you should be using application scope on an object related to user login. User logins are related to session scope.

Also, it sounds like you don't understand how roles work. A user can be assigned more than one role. For example, Joe VP may have ordinary-user, auditor, and manager roles. And Mary Flunky may be temporarily assigned an "approver" role while Tom Grunt, who normally holds that role, is out on vacation.
 
Vasilis Souvatzis
Ranch Hand
Posts: 109
1
Netbeans IDE Chrome Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The ApplicationScoped annotation seems strange I know, but it's the same in the official tutorial. Haven't tried with a DatabaseIdentityStore though, had to go directly to a custom one because they wanted some other stuff to happen prior to authentication.

I think the issue is at the user checking logic and I'll check it tomorrow. When I'm calling the validate credentials method, first I check if it's the admin username to log them in from the database directly. If it's not, I'm calling the database to see if the user is present. If yes, I log them in. If not, I call an external service to get the user's data, persist them in the database and then log them in with the database. With some logging, I realized that when the user managed to login with the previous person's credentials, the Identity Store didn't kick in, the backing bean got the credentials but probably the session had it from the previous attempt and so log that person in. I'll definitely change the logic tomorrow and see if it helps.

So maybe invalidate the session whenever I redirect to the login page? Or when a person tries to reach a resource out of their role? That's why I'm not sure if it's more of a JSF issue or Security. That's probably on me though, I highly doubt the Java guys hadn't thought of that.

Regarding the roles yes, they can change and in fact they do change in the database. Every user except the admin can change roles. When I fetch the user in the identity store I check their role and then pass the role you see in the CredentialValidationResult. So even if they change roles, they'll still be redirected to the correct resource. That's the idea of course, not sure if they've tested this.

I'll dive into the docs and see what I can find, hopefully I'll have an answer in the next couple of days...
 
Tim Holloway
Bartender
Posts: 20842
125
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I said that users could have multiple roles, I didn't mean specifically change roles. I meant that a single user can have multiple roles at the same time. You can add to or remove roles from a user, but a user is not restricted to a single role at a time.

Something smells here. In the original container security, you didn't - in fact, you couldn't - look up a user's roles. All you could do was ask if the user had been granted a specific role. Being able to ask what roles a user had wasn't supported because it's a security problem. An attacked could simply find what roles the user had and assault the parts of the webapp that were restricted to those roles. It's the same reason why you couldn't look up the password for a user login ID. Too easy to go fishing when the system volunteers security information.

I did a quick look at IBM's take on the subject, and all I can say is that it's both incredibly messy and incredibly intrusive. The original container-managed system allowed you to switch the identity store from XML to JDBC to LDAP without changing the webapp at all, rather than hard-coding it into the webapp (and it's a LOT easier to test with an XML file when your production system uses Active Directory).  Granted, it had its shortcomings, but it didn't demand that you pile on annotations or dig into JSF internal data objects.

Anyway, accessing a Forbidden resource isn't supposed to log you out. It merely forbids access to that particular resource.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!