I have a user permission system in place where i have a set of permissions within the database, for example
id
Permission
1
POST:CreateBooking
2
GET:AllBookings
And i have another table (junction table) where i put dependent permissions such as
if i want to create a Booking, i need to fetch Package details and so POST:CreateBooking requires the user to also have GET:AllPackages permission.
There's a template system in place as well, where the users can group multiple permissions together and once that template is assigned to any employee, that employee will get THAT set of permissions and it's dependent permissions.
What my nodejs system does is that when user logs in, it fetches all permissions from DB and puts it in a redis set from where on each request, the permission is checked against user id.
Is there any tool from where i can do exactly this but in an intuitive and better way?
I tried keycloak but i don't know how to cover my needs mentioned above.
Thank you
if I'm understanding correctly and trying to generify your scenario, you have a classical situation where:
You have groups which can have multiple permissions assigned;
groups can be created dinamically;
each permission correspond to a specific functionality.
So, implementing the OIDC (Open Id Connect) protocol might fit you needs. As you suggested youself you might be interested in a OpenID provider (do not reinvent the wheel) keycloak is good, you can give a look also to Vault Hashicorp.
So assuming that your backend have an already existing framework to handle security and permissions (eg. Spring Security) you can produce JWT token with the OpenId provider and check throught PreAuthorize claims (permissions) inside the token.
At the end your security layer it's just an annotation you need to insert before your method controller or before you class controller.
Behind the scenes, instead, this is what will happen:
Your user connect to your app;
User insert username and password -> the Open Id provider gives you a JWT
Your Front End app everytime it make a REST req will send also the JWT
The back end controller method called it's under authorization
Given the public keys of the OpenId provider, the validity of the token it's enstablished
If the specific permission claim it's found inside the token, the request can be elaborated else a 403 Forbidden it's returned.
OIDC - as the conceptual model/backdrop to any tool of choice, is certainly a popular/good choice, but as long as you're willing to deal with an element of complexity - the understanding required to implement an OIDC arrangement (- think of it as a possible investment - effort up front with hopefully the rewards tricking-in over time); e.g. OIDC is an ideal choice for supporting SSO (Single Sign On), especially when it comes to supporting/allowing for authentication/login via providers such as Facebook, LinkedIn & Google, etc (- as well as more Corporate OPs (OIDC Providers) including AAD/Azure AD).
Try to first step-back, and consider the possible bigger/future picture, before selecting a tool based upon only your starting/current requirements.
Related
I am designing a REST API in which there are several user types:
disabled user
standard user
support user
admin
root
for each user, there are certain properties assigned to them in a relational database.
For example files, messages, payments, ...
Let's say I want users with higher ranks to be able to handle data related to lower ranks (e.g. an admin can modify a standard user's properties)
How can I implement it in a way that I make sure the authorization functionality is separated from the process (CRUD process).
I want something like this:
api.Get("/users/:id", authorization, processHandler)
I am using the echo framework and Golang, but I don't think that really matters. I am looking for a general solution independent of language.
Maybe you have Roles and Permissions problems, that problem has a solution when you control the access level by JWT token (for example).
You have a table with enabled system permissions and your users have associated or assigned permissions, this "association" can be managed through the Roles and Permissions manager (CRUD). So when you need to associate permissions to a user, you have to create a relationship between the permissions and the user. Then, send the new "state" in the token (JWT).
So finally you have a "middleware" on your routes like this
api.Get ("/ users /: id", authorization, processHandler)
And your authorization role has the responsibility to check if your user has the permissions to use the endpoint.
I've read about security best practices saying that inactive user accounts should be disabled and even deleted to avoid security issues like unauthorized use. I can see that being true for regular username and password authentication sites, however my application was built to work only with Facebook groups and as such the only way to login or create a new account is to use the Facebook login.
The argument can be said that someone malicious could take control of one of my users' Facebook accounts and then use it access my application. Although that is true if they have control of a Facebook account my application would never know it's a malicious person so I don't see that as a valid criteria to use in determining if the account should be disabled.
Furthermore if a user is inactive and wants to become active again since it's Facebook login there really is no reason for them to go through some kind of reactivation process like confirming their email or changing their password.
I must be missing something here because it's certainly mentioned as a best practice to disable accounts but since my only login method is Facebook (OAuth) I can't come up with a valid reason to disable/delete inactive accounts.
Regarding other methods of unauthorized access I have security measures in place so I'd like to keep the answers relevant to the login method.
Please enlighten me if I've missed something.
If you have decided that your application needs to use Facebook authentication, then your system's identities will only be as traceable as Facebook's identity management permits. (And don't expect Facebook to help you by disabling / blocking users at their end ...)
You need to design it accordingly:
Don't make any assumptions that users will behave properly.
Don't rely on login controls to keep out malicious users.
Put in your own (sufficient) defenses against malicious behavior into your own system.
You are correct that disabling an account in your system won't achieve much if you also allow the user to (easily) reenable it. Given that it is easy to create (effectively) untraceable Facebook accounts, the chances are that a typical malicious actor will not just rely on old accounts. They may use a brand new account and connect from an IP address that you have never seen.
There are some things that you could do though. For example, implement mechanisms to do the following:
Make sure that users simply cannot upload dangerous content (e.g. files with trojans, web content with dangerous links or scripts.
Allow administrative locking an existing account or OAuth identity,
Allow blocking of creation of accounts or access in from specified IP addresses or ranges,
Keep an audit trail so that you can watch the history of user behavior.
What Cross-Domain Single Sign-On implementation best solves my problem?
I have two domains (xy.com & yz.com) which already have their own database of users and are already implementing their user authentications separately. Recently there has been the need to implement CDSSO so that users dont have to log in each time they try to access resources from both domains.
Ideally the CDSSO implementation I hope to use should allow custom implementation of authentication, as I hope to call API's provided by both domains during authentication to confirm a user exists in at least one of the domains user database.
I've been looking at Sun's OpenSSO which seems to provide a means to extend its AMLoginModule class yet this seems to be a long thing and more annoyingly they seem to stick to GlassFish.
I've also considered developing a custom CDSSO to solve our needs. Is this advisable?
Is this achievable using Suns OpenSSO considering the disparate user database as I there will be no need to make use of the User db that OpenSSO requires?
Are there any simpler means of achieving what I intend to achieve?
In addition both applications which exist on the two domains were developed using PHP. How does this have an effect considering Suns OpenSSO is based on Java EE?
Are there any clearly specified steps on implementing OpenSSO and or any other SSO implementations from start to finish?
I suggest you to use simpleSAMLphp in order to deploy an Identity Provider and 2 Service Provider (for each app).
SimpleSAMLphp allows you to select multiple authentication source and is not hard to build your own authsource that consults the 2 databases.
My experience in SAML says that the fact of not consolidating the Identity of the user in 1 unique authsource is a bad idea due several reasons:
* identity conflicts: what happen if you have the same user registered with different mail (if that is the field yoy use to identify the user) and you try to access? You could be logged in different account each time.
* what happen if you add a 3rd service, do you gonna add a 3rd database
* what happen if user change its data in one app, the other gonna be no synched?
* what happen if user uses different passwords?
I recommend you to execute a migration process before adding the SAML support and build a unique database for all your identities and unify the registration/edit profile/password recovery process of both sites in one.
SimpleSAMLphp has good documentation, but I can provide to you any documentation related to the process that I suggested.
Let me start by saying I really like Deployd. I want to use it in production, but I want to incorporate OAuth and social logins, so I installed the dpd-passport module. It works great, except for two little (big) problems:
When a user signs in via an OAuth provider (e.g. Facebook, Twitter, Github) a new user record is created...but if the same user clears their cookies or uses a different browser to log in, a new user record is created.
If I do something clever (read: hacky) and assign users with social logins an ID based on the socialAccount and socialAccountId (something unique but constant for each social account), someone could use the standard method of user creation to spoof a user by making a POST request to the /users endpoint if they knew that user's socialAccount and socialAccountId.
My question is: How can I A) prevent #1 from occurring, or B) disable the standard method of user creation without also preventing OAuth user creation?
Has anyone ever successfully used Deployd and dpd-passport in production? If so, I want to speak with you...
Thanks in advance!
First of all, I think you haven't added the custom fields per the docs.
https://www.npmjs.com/package/dpd-passport#requirements
I hadn't either, and observed the new user feature (because it couldn't lookup the response from the auth service to find the user from before). Adding these fields fixed it.
Also, there is a google group here:
https://groups.google.com/forum/#!forum/deployd-users
Hope that helps.
I'm starting on a project to allow an existing web application to use active directory for authentication but leaving authorization within the application. I want to start off simple so I was thinking a user would type their AD username/password into my existing login form, I would then do an ldap bind against the AD server to authenticate the user.
Once the user is authenticated, I would pull that user from my database which has all the authorization information as to what functions the user can see.
My question is what is the best AD element to store in my table to make the association? In the past I've used username but after looking at some of the elements that AD returns I was wondering if I should use the security ID or GUID or something else?
I've been burned when a username changes like an employee gets married or divorced... so I know that is brittle.
I was targeting windows 2003 AD and above if that makes a difference; this is for a product where some clients have large AD forest and some are small networks.
Storing the SID is the most reliable approach; this is the unique ID that all Microsoft AD things use, security groups, permissions, etc.
If you're building on .Net you should seriously consider .Net 3.5, there's a new namespace System.DirectoryServices.AccountManagement that greatly simplifies code here and gives you nice neat objects to go against.
Unless users share computers, why not use Windows integrated logon? Much easier on the users, easier on yourself as developer, and more secure (one less place a password can be sniffed).
Need I mention that allowing user identities to change is poor corporate security policy? Makes traceability harder, permits some novel attack vectors, and gives you this headache.
As Nick mentions, the SID is a stable identifier, but not something you should ask a user to enter for him/herself!