I'm trying to create a custom login for my flex web app with spring-security.
I have an working version where we use the channelset.login with blazeds.
The problem i have is that i would like to split the authentication and the authorization.
I would like to ask the user to make some choices after the authentication to determine its roles.
Since the roles the user is authorized to are determined by this choices.
This means the user has to be authenticated and then the client needs to do a service call to the service and then the authorization process needs to take place.
Does anyone know if this is possible and have some tips of how this can be done?
Thanks in advance,
Arjen
Yes, that doesn't sound too far-fetched.
You can store the user roles in the database, make each role for new users something like SIGNUP which will only allow the user to signup, once his new role is determined, simply update that role and restrict the new role from being able to update the role again, unless you're admin.
You can also override the authentication process to do whatever you want to do: http://mark.koli.ch/2010/07/spring-3-and-spring-security-setting-your-own-custom-j-spring-security-check-filter-processes-url.html
The session object might need to be refreshed if you're using some form of ORM.
Related
I would like to implement claims based authorization in a Web Api project. I understand the idea of claims and can manually add a claim to a user and authorize a request based on it. However, I don't know how I should manage the claims, assign them to users and update them in future.
For example, say I have a Product entity and ProductCreate, ProductRead, ProductUpdate and ProductDelete claims for the CRUD operations on this entity. So I have a few questions:
I can store the claims in the DB, but what is the best way to add the "default" claims to a user on registration?
If I add new functionality to list the products which is only authorized if the user has the ProductList claim - new users would get this claim, but how would I add this claim to all existing users in the system?
Should there be a limit on the number of claims associated with a user? In a larger system with many entities, a user could end up with hundreds of claims
As I said, I know how to physically add the claims to the user etc., but it's more the bigger picture of the process of how you would manage claims and users in a real world example.
Thanks!
UPDATE
Thanks Brendan, I appreciate your help! I don't know if I'm misunderstanding something fundamental or if the answer is staring me in the face - either way, I'm not getting it.
So I have web api and would like to give granular access to the different controller methods. As the Admin, I want to be authorized on all calls so I should have all claims. Registered users should have read access to some methods and you as a moderator should have update and create access to some. My understanding is that these claims should be stored in a DB (SQL server in my case) somewhere and "assigned" to the user when they register. Using Asp.Net Identity, each user's claims would be stored in the AspNetUserClaims table, so when they login they get all their claims in the token by default. Simples!
What I am missing is the process of how you would handle the claims that should be assigned to a user when they register, what claims should a Moderator get etc. and how would you add / remove privileges. It doesn't seem right to me to have this in the code as adding a new claim in the system would require a rebuild and new deployment.
Also, if I add new functionality which requires new claims for different types of user, how would I make sure that the next time an existing user logs in they get the new claims as well as the ones they were assigned when the first registered.
I hope I am making sense, I may be mixing up some of the Role-based thinking with some of the Claims-based thinking which could be the source of my confusion. I just haven't seen any examples of how you would manage an application with many, many claims in the real world.
Thanks again!
That's exactly the same question and issue i'm running into. All I found is info on how to create a claim using the manager classes but nothing on where to manage these claims.
There can be different combination of access to give to a user and if my UI is a disconnected UI from my API, I don't think i would want the ui to manage these claims for me.
Other than mucking and creating a claims manager class with a claims table did you figure anything built in that can be used?
I want my website to be seen by anonymous users. and i don't want it to have a login /register user part.
i just need one user as administrator and its username and password is chosen manually.
what is the best practice to implement this login part (website has only one user for ever).
my question is how to implement this one user login part, where store username and password and does it need a table in database?
For me - if you're having such a simple system, then merely storing the username / pwd in the web.config is fine.
I'd create a helper class to wrap up talking to the config file (ConfigurationManager.AppSettings on MSDN) and use and evaluate a simple "logon" action.
No table needed.
Finally - make sure you add the AuthoriseAttribute to your controller that will be doing the admin actions...
HTH
Simplest way - just delete the controller and the view responsible for registering new users, change the routing to the login page and you're set.
I'm trying to figure out how when using the default asp.net forms authentication stuff one can change the roles that a user has dynamically. In our case a user has access to many accounts and there roles can change per account. This doesn't seem like rocket science to me but I can't figure out I would do this. Does anyone have a experience trying to do this or a link that would be helpful?
UPDATE:
Just to clarify. We know at startup that User X has access to account #1 with roles 1,2,3 and account #2 with roles 1,2.
So first off I have to handle this part of the problem. Getting their roles based off their current account. For this I think I'd use a RoleProvider. The problem I'm trying to solve though is once ASP.Net has a User how do I tell it to invalidate that user or refresh that user so it would hit my custom RoleProvider (or what not) again.
Roles.AddUserToRole() should take care of adding the user to a role.
For removing: Roles.RemoveUserFromRole()
http://msdn.microsoft.com/en-us/library/system.web.security.roles.aspx
Our site has got two ASP.NET membership providers. The built in one, and a custom one (SqlMembershipProvider.
I am able to log into both no problems, but I don't necessary require the ability to have both logged in at the same time.
The issue I have is as follows:
User "person_a#site.com" logs into the built in provider. They then navigate to the section of the site where we require the custom provider.
On this page, I can check if they are authenticated, and get their username. I can then get a MembershipUser object form the custom providers GetUser method. (HttpContext.Current.User.Identity.Name)
It is possible (and very likely) that the username "person_a#site.com" could also exist in the users for the custom provider.
But, I don't want them to be logged in here, as they haven't authenticated against the custom provider.
So, is it possible to check which proivider HttpContext.Current.User was generated from.
Hope this all makes sense!!
Yes, if you notice on the RolePrincipal there is a property called ProviderName.
Typically when people roll their own providers they omit usage of this field.
In your case, simply modify your custom provider to identify itself, if it does not already, and check that property of the user.
Our SSO login process uses Forms Authentication against a custom user store in SQL Server.
One of our new security requirements is to only allow an account to have one active session at a time. So any time a user logs in, we will check to see if the login credentials are already active, and preferably prevent the new user from logging in again until the other session ends. Alternatively we could force the other session to end, if that would be easier to implement.
Is there a simple way to do this with Forms Authentication? We've considered a custom approach where we track each session in the database, but it would be a lot of work and we'd probably have to modify all of our applications to detect the session_end, which I'm hoping to avoid. I figure there has to be something in Forms Auth that handles this.
I've seen the MembershipUser.IsOnline() method, which seems ideal, but we're not using a Membership provider.
UPDATE: Just to be clear, I do not need to check whether the current user is logged in, I need to know if somebody else is already logged in using the same account.
Try this:
System.Web.HttpContext.Current.User.Identity.IsAuthenticated
If I understood you correct, you would need to store the last activity state based on the user id.
Membership.IsOnline() is implemented by checking the LastActivityDate property persisted in the membership database.
So somewhere, you would need to track user activity.
You could maybe implement a httpmodule that updates a timestamp for user activity.
If the HttpContext.Current.User property is not null then they are logged in. And Identity.IsAuthenticated is true.