Logical Question
Backend implementation
I am implementing User Management Module in Web application. I have three table User, Role and UserInterce. The user table has ManyToMany relationship with role table and Role table has ManyToMany relationship with User Interface table. So whenever Server return user object, the system will verify it's role and that role has access right to which user interface.
this is background overview of backend implementation.
Front End implementation
Whenever user login into the system,server will return user object. I want to implement access control in form basis. e.g. emp role do not have access right to add button where admin role has access right to add button. To implement form based access control i would require to create another table at server side which has information about ui fields and that will be has relationshiop with User Interface table.
can some one provide better way of doing same thing logically ?
If you don't need to have possibility to edditing role's permissions in runtime, the best way is to use spring JSP tag library and build your frontend using spring security tags
http://docs.spring.io/spring-security/site/docs/3.0.x/reference/taglibs.html
Otherwise, using some table for storing your permisssions is the only option to do that
Related
We are removing User, User Group and Permission models from our backend in favor of Auth0.
Our first idea was to just delete User, Group and Permission tables from DB and replace related foreign keys with varchar field. In this field we would then enter IDs that we get from Auth0 in JWT (pointing to something not present in our DB).
Is this good approach? I somehow feel that there must be more "relational" way of doing this.
Generally OAuth will not do all of the permission checks for you. Instead it gives you general mechanisms to sign the user in and issue + validate tokens.
In most real world architectures you also need to manage a second level of authorization in your back end - using domain specific user data for roles, permissions etc.
A couple of write ups of mine may help:
User Data Management
API Authorization
Auth0 Community Manager Dan here,
In this scenario you may be able to leverage the RBAC to replace your existing users/groups/permissions setup.
You would register a user's roles and the associated permissions of each role in the Auth0 dashboard or programmatically via the management API. Then you can setup a rule to add user roles to the token.
To connect this user to your existing user data store you can store the Auth0 id, similarly to how you have described.
This allows you to lookup the user when the token is received, and to associate any permissions or roles the user has. You can make roles API-specific by adding a prefix to the role, or have roles be general depending on your needs.
I'm using Identity Server 4, Asp Identity, EF Core and one database.
I have 3 projects at the moment
IdentityServer - Contains all data contexts and all migrations with my app tables
Api - no context, no migrations however I need to access database somehow from here
Clinet - javascript
The question:
How do I access data context from IdentityServer project and still have all settings (db connection, etc) in one place. I understand I can reference IdentityServer from API and use data context but it seems not right to me. What is the preferred way to do this ?
Since you are interested in this option, I've decided to move my comments to this answer.
First of all, IdentityServer is not the place for your app tables. These are seperate contexts and separate migrations. The preferred way is to maintain the separation of concerns.
As I explained in my answer here, you don't need a relation between the login user and your business context. Instead create a user in the business context. The login user has a different purpose than the business user.
I don't have code for you, but you can take one of the sample apps from IdentityServer. Adjust the API to use your business context. In that context add a user table (which links to the sub claim) and the fields you need for the business context. BTW it doesn't matter if the tables are in the same database, just don't mix the contexts.
In IdentityServer: if the user may register for one website then you can extend the registration form with a drop-down of available websites. Or a list if the user can register for multiple websites.
Now it depends on the chosen strategy. You can wait to register the user in the API, but I think it is far more easy to register the user straight away. There are other options, but here's one where it is part of the IdentityServer configuration (without adding business logic to IdentityServer):
Extend IdentityServer to call the API after registering the user. For this I would add a table in the IdentityServer context with URLs to register per website. When the login user is created, call the configured API(s) to register the business user.
In the API you need to add the method that IdentityServer can call to create the user, linked to the sub claim and including the required user information. This way you can suffice with the sub claim to identify the login user and link this to the business user.
You can use a similar strategy for client apps. Extend IdentityServer with an API method to allow client apps to register users.
If you want to withdraw access, you can delete the login user without having to delete the business user. Which you don't want if you don't want to destroy historical information. You can also use claims to specify if the user has access to the website without having to delete the login user.
I have created an integration profile CORE_AKTANA_DI through which data for objects will be loaded into my Salesforce instance through a third-party user. I have provided "View All" permission for all objects to that profile. However, since this is a global Salesforce org, hence, there is data for other countries as well in this instance.
I want the user with the profile to see only data of France i.e with country "FR". In this case, my only choice is to:
Remove the "View All" permission of the profile from all objects.
Give the user a role such as "FR-Corp".
Create sharing rules for all objects with "Private" OWD and share with this role.
The problem is that since this is an integration profile, I cannot assign a role to the user with this profile. Also, it is not plausible to create sharing rules since there are a lot of objects with private OWD.
Same problem occurs by assigning the user to a public group, i.e a lot of sharing rules need to be created.
In this case, please suggest me the easiest possible options.
Actually, how to solve your issue is dependent on business process you are trying to implement. There are few ways:
sharing by hierarchy: setting proper roles and checking 'grant access using hierarchy'
sharing rules: setting proper sharing rules, owner/criteria based
manual sharing: using button
sharing using apex: using share object of any corresponding object
I think, this document will be useful for you.
I don't think what you say is correct:
"The problem is that since this is an integration profile, I cannot assign
a role to the user with this profile."
In my org we have a few integration connections. Each connection is anchored by a SF user license which has both Role and Profile. You should likely give the integration it's own user license and name the user something like "Integration (Fr)" Set the Roll up with appropriate hierarchy position, permissions and sharing rules and once you've done all the token resets needed set as API login only & password never expires. That should do it unless I'm missing something.
I have a custom field in the Salesforce User object. I am trying to work out permissions. I only want the User's manager and System Admins to be able to see this field.
Looking at the field-level security options, I see: Contract Manager. I worry that if I check this, ALL contract managers will be able to see this field. Is that the case?
Is there an easy way to accomplish this security policy and test it in a sandbox where I am not allowed to have many users?
You are correct, if you allow the Contract Manager profile to view that field via Field-Level Security, then ALL users assigned to that profile will be able to see the field, regardless of whether or not the user actually rolls up to them.
You should be able to show/hide this field based on some more advanced logic by embedding a small VF page into the User page layout. This will still require you to make the field visible via Field-Level Security, however, and will not allow you to hide it from other managers if they have access to the API (it would only be hidden from them on the page).
Making the field visible to contract manager will make it visible to all contract managers. However, there is a fairly simple formula that will allow you to enforce this securely.
1) make secret field not visible to contract managers.
2) Create a hierarchical relationship to the contract manager on user.
3) Create a formula that checks if the running user is the contract manager of the user you are looking at.
IF($user.id == user.contract_manager__c,secret_field__c,'only this users contract manager can see this.')
i'm doing with silverlight 4 for consultation booking system. what i wondering is, in my application required multiple kind of user register and login. admin having different format of admin ID, lecturer having different format of lecturer ID. i'm trying to implement with silverlight for role and authentication merchant. i think might because of silverlight membership can be done easily with asp.netmembershipprover, i could not find any resource to edit the default form for it or custom made the membership merchant for my application. may i know is there any article or resource you know on how to implement this, or any idea you can suggest to me ?? Thank you
Resources i found:
http://www.silverlight.net/learn/graphics/file-and-local-data/isolated-storage-(silverlight-quickstart)
i thinking of using the isolated storage to store the user logged in boolean but sound like not so secure
http://msdn.microsoft.com/en-us/library/ee942451(v=vs.91).aspx
the resources mention of using the default asp.net membership but no comment on how to edit the default set.
You can use default MembershipProvider to manage general user information such as username, password, security question, login etc. Then you create additional table to store your own information, of course you need to create Page to manage these data by yourself.
Table: aspnet_users
UserId
UserName
...
Table: YourCustomData
UserId
AdminId
AdminText
...