I am sure the question that i am going to ask must have been answered a billion times before...but I have been reading so many articles about membership and role management that my head is spinning right now and i think i am a little confused too.....
I am really looking to implement role management for Admin interface of my site. I have a general idea about membership and role management but really dont know where and how to start implementation of the same on my site....
If some one could direct me to any tutorials or examples or any walk through that implements role management then it will really be of great help.
Thank you in advance
This question has been askied before.
see ASP.NET Roles with Windows Auth
If you implement your own role provider for example and you store the data in say a database, then you would need a UI to manage those tables. Most likely you'll have a users table and a roles table and a table in bettwen to do the mapping.
Related
we have a big distributed and multitenant system with all sorts of accounts :
- admin and backoffice users account
- customer account
- cashier account (tenant : there is one or many more cashier for each client tenant)
All this account are sharing more or less the same lifecycle (account created, grant on some ressources, deny account, password reminder...)
But they are not used in all applications of the system : some account would be used on specific or just two application for example.
Furthermore our system should have the possibility to have a bridge with a CMS for the customer management, or the backoffice users account could be authorized one day against a ldap...
So the question : we are searching for the best way to model our right and authorization service(s).
One idea is to create one service in order to manage all types of accounts of any kind : that is a SOA way to modularize our system
And one idea is to create different services : perhaps much more a micro-service oriented way of thinking...
What are your opinion ? I am searching some advices and feedback on this two different approach or perhaps an alternative that we habve not thought about...
If you are looking for any open-source solution for your problem, you can have a look into keyclaok.
Keycloak also got place in Thoughtworks Technology RADAR.
It is very promising solution and has LDAP, Multi Tenancy support also. checkout keycloak features.
There is paid solution like ForgeRock is also avaible.
Coming to feedback which you have asked about SOA or microservice way of implementation here (You will get different feedback/advice on this)
It will be better if you have a service to take care of access and authorization management and other to look into user details. If you meant that having different services for different account then note that Having one service for taking care account is still considered as Microservice approach as there is one dedicated service to perform single set of tasks.
You can have User-Service for user information management and a authService to handle access and authorization of users. check.
I have just developped a Human Ressource WebApp in Laravel.
So in this app, I have my user database.
Now, I have 2 old apps, that I'm about to rewrite / Migrate to Laravel.
The first one is to manage employee payments.
The second app is for monitoring my salesforce in field.
So, Basically, I will basically rewrite them.
My Question is about architecture. I will develop those 2 apps separating APIs in Lumen / Laravel for each app, individually, and then writing clients in Angular2.
I will use OAuth2.0 to set authorization and scopes between apps.
Now, My indecision resides on Database part.
Should I keep database separated, include database in the same schema, or how should I deal with my databases.
Today, I have 1 DB per app, but also, I have redundancy in users: Each App works with the same users, and so duplicate this info.
Right now, When User is created in App1, it calls APIs to create it in app2 and app3. This is not so nice, IMHO.
So, I think I would like to have a single User Database, but I don't really have experience of that:
should I extract User's info in a central database for all users, should
should I keep User's info duplicated between my DB?
if I keep it in 3 differents DB, how should I make JOINs, transactions, Foreign Keys, etc.
I know there is not 1 answer, it depends of what I want, but this is also my problem, I don't know which question should I be asking to make my decision???
It is important to mention that I don't have so much traffic, max 1000 users, and they all belongs to my enterprise, it will not increase to much. So, really, make a scallable app should not be my priority right now.
Any Advice will be appreciated!!!
Since you have shared databases between your apps, the common practice is to have it in the same Laravel/Lumen app.
The way you can achieve this is separating the apps inside route groups, namespacing the controllers hierarchies of each app and declaring inside each model the connection you will be using for this model.
This way you can use the same DB connections for all of your apps, and share the same data without the need of duplicating it.
I want to design a database for a student portal. I want to create a student role, so for every student I need to create a user and assign the users's role. It seems like many users will be created. Could there be any problem such that large resources will be needed.
The number of user accounts is not the issue - you can create as many as you think you need. The issue that is of more concern is how many concurrent user sessions - users logged into the database at the same time - will there be? Each user needs memory to do their work and this must be allocated. If you have more simultaneous user session than memory can accommodate, this can be a problem. Read more here and here. If you will have a huge number of concurrent users, consider a shared server connection setup, rather than the default dedicated connection.
Another thing you need to be aware of is the financial cost implications depending on whether you have a per user licence.
However as others have already mentioned applications usually connect to the database using a single set of credentials, end users are not usually defined as database users, and therefore you would not be able to use the database defined roles to differentiate between the permissions.
You could likely have two database defined roles DBA or SYSADMIN, and PORTAL_APP.
The end user roles would need to be handled within the portal application, and this should be consistent on the front-end and the back-end of the application.
My team will develop an internal (known users) application that has an architecture based on Java as front-end and PL/SQL as back-end. So, currently we are thinking in a better solution to manage the user/permissions, and we have two options:
Each user has their own database account, granted with the permissions. Currently the legacy system use this approach and I don't like it because it manages permissions based on database objects' granularity. So, I believe it is a bad choice to have a database connection per user. Can you see more cons here?
Build some tables at database to store the users and theirs permissions/profiles and build a PL/SQL procedure to do the login, generating a token and include a parameter to all others PL/SQL to verify this token and then authorize (or not) the execution.
So, you can ask me: why not just manage your permissions in your web-application? Answer: Those PL/SQL are already done and are used by all legacy systems, and this web-application should behave according it (ie. User permissions should be managed by the PL/SQL and its granularity based in please.)
How do you proceed in this case?
I think using the database's built-in mechanism is always to be preferred over rolling our own. And that applies to logging in users as much as anything else.
The biggest single advantage of dedicated user accounts is that we can link a given session with a named user. Well, yes, duh. But the point is, doing thinks like auditing user activity or tracing a performance issue in some process is way more difficult in web applications with generic accounts.
To address your main objection, we don't have to manage database privileges at the user level. That's why we have roles. For normal users, a role will provide sufficient privileges.
So:
define a set of roles which match the various business jobs your application serves.
grant system and object permissions to those roles; remember that roles can be additive (i.e. we can grant privileges on a role to another role).
grant roles to the users.
Find out more.
oracle experts.
My client of mine wants to deploy an application that has to hold credit card numbers in a database. The client is obviously concerned with security.
We are particularly concerend with one painful issue. How can we make sure that only authorized users with a 'business need to know' are allowed to access the data? How can we protect the data from the DBA?
One obvious solution is to encrypt at the application level. We don't want to do that.
An oracle product that came up as a possible solution is Orace TDE (Transparent Data Encryption). It seems to cover the on-disk encryption case well. However, there have been disputing claims if it can be used to hide data from someone with DBA privileges.
I want to be very specific about the use case we're dealing with. We have an up and running application, 24/7/365, that is doing data access constantly. That means that the Oracle wallet is open and data is being decrypted by the database. AT THE SAME TIME a DBA should still be unable to access the data.
I know that Oracle is marketing Oracle Database Vault for this very issue. Given that all I want to do is block DBA access from just one particular table, do I really need the Vault or can I use TDE?
Assistance would be much appreciated,
Or
My guess is that you need Oracle Vault. TDE makes it impossible to read the datafiles but a simple select will still retrieve the data unencrypted.
But ask the dudes or dudettes who made the claim that TDE is sufficient, to explain how to do it without Oracle Vault.
Edit: Two threads on this issue:
http://forums.oracle.com/forums/thread.jspa?messageID=3249532�
http://forums.oracle.com/forums/thread.jspa?messageID=3261345�
"there have been disputing claims if it can be used to hide data from someone with DBA privileges."
Probably because there can be conflicting ideas about what constitutes DBA privileges. There is a DBA database role, a SYSDBA privilege and someone who can login as oracle (or Administrator) to the server at the operating system level, each with higher privileges
Privileges can be revoked from the DBA role, so that is even more vague.
VPD can ensure that, for example, the credit-card column is only visible to users logged in from a specific IP (eg the application server), as a certain user or with a certain role.
While a user with DBA role would be able to change the VPD privileges, or grant themselves the appropriate role or impersonate the relevant user, this would show up in the audit log.
i came across a similiar problem with one of our customers. During the evaluation process i have found a possible solution from a german security company. It seems they have developed a system that should prevent the DBA to access any sensitive data. Take a look at their website. It didn´t take a deeper look yet, so i cannot give you further information about this solution.
There are certain alternative companies with DB encryption and access control solutions that implement a strict separation of duties between DBA and Security Admin.
You may want to take a look into D'Amo from a Korean company, Penta Security Systems.
Disclaimer: I have worked as a DB consultant and deployed the solution to many of my customers.