Currently I am using database accounts as my authentication schema and as a result anyone with a valid database account may login. I would like this to be more restrictive. All my users have a prefix in their user account names which specifies the group they belong to. An example would be dev_john, qa_cindy, etc. I would only like a specific group with a certain prefix in their username to be able to login. Database accounts seems to just allow all. I see there is a custom auth, but I am unsure how to get databse users from here.
I think the problem with this would be how to check the Oracle users' passwords from within your custom authentication function. Hopefully there is no way you can find out their passwords to check them, so how can you establish they typed the correct password? Maybe there is a way, I don't know.
However, perhaps more appropriate for this rule would be an authorization scheme. The user can log in, but if their username fails your authorization scheme test, they can't access the application. The test would be a PL/SQL expression like:
:APP_USER like 'QA%' or :APP_USER like 'TEST%'
When user DEV_JOHN logs in, the log in succeeds but all they get is a page saying e.g.
Only QA and TEST users are allowed to access this system.
Related
I am creating a flask app to be used internally in my company. I would like to restrict what a user can do it based on its login ID. I read a lot about using LDAP3 but I don't think I can do what want which send the login ID to the server. There I would have a table which will register which part of the system has the permition to edit. If it try to change somenthing not permited the app will retrieve a warning message.
I won't to do that to avoid having to create a separate login functionality just for this app. I read that I should use AD authentication but I am not very familiarized with that and I would also like to avoid having to ask our IT department to create user groups there for each part of my system.
I know that I can do that using ASP .NET (at least I did once).
Any guidance will be apreciated.
I think you are looking for Role-based Authorization.
In order to use this functionality you will need to implement roles on your model file per the Data-models documentation.
This will allow you to assign users a role when they are created, and you can use a decorator on your routes to 'require' the user to have the role you want them to have before they access the endpoint.
I'm trying to create an App which has a log in page where user should be authenticated using azure AD. Basically the App has a log in form where user puts his id and password from ad and django should check with ad and allow him in or not. Later on ofc would like to add permission depending on AD group.
So far I searched a lot on the internet and found nothing. Could you guys help with some example or link to documentation what I could use.
First of all, I'd like to suggest that you don't do that.
What you are asking for is ROPC flow: https://joonasw.net/view/ropc-grant-flow-in-azure-ad.
Usage of this flow is not recommended unless this is for migrating a legacy application (which is the original purpose of ROPC).
It also won't work if the user has MFA, an expired password etc.
There is usually no reason why you'd want to handle user passwords when using a federated identity provider.
In Amazon Cognito's User Guide, in the page “Configuring User Pool Attributes”, there is this paragraph (with added emphasis):
“If your application does not require a username, you do not need to ask users to provide one. Your app can create a unique username for users in the background. This is useful if, for example, you want users to register and sign in with an email address and password.”
I want to do precisely what the paragraph says: while users sign up, create in the background a custom user ID for them myself, because I need these IDs to follow a specific semantic format, that embeds tenant context into the IDs (something like “T01234#U01234567“, meaning “user U01234567 inside of tenant T01234”).
The users won't know of their custom ID, they will feel as they've signed up (and later signed in) with their emails (or through 3rd parties like Facebook and Google, if possible in this set up). But in the background I will create these custom IDs and store them in their username attribute in the User Pool.
The reason I want to store these iDs specifically in the username attribute is because it is un-mutable and unique, but most important because I will need to query Cognito's APIs (ListUsers, AdminListGroupsForUser, etc.) using these custom IDs as filter, to give my customers some user management capabilities. The username attribute is the parameter for these APIs. Therefore, I cannot use User Pool custom attributes here, since they are not accepted as parameters of these APIs.
The reason I post this Question is because, while the documentation recommends this as a possible setting, there is no specific information on how to set the user pools and sign up flow to support this specific use case.
What is the general settings layout of this? To start with, in the option “How do you want your end users to sign-up and sign-in?”, what do I have to put there in the scenario I described? If anyone can give any additional pertinent information, it would be very helpful, as the documentation feels somewhat opaque.
Thank you very much for those who've read this.
You probably will need to deal this in your frontend.
When your user start the sign-up process, you will need to generate the username based on your requirements and send the request to Cognito User Pool using that generated username + e-mail.
For Cognito User Pools this will be transparent because in the request it will receive the username, the password and the user e-mail. Off course you will need to allow login with e-mail and password.
If you don't want to do this in the frontend you can create a backend with public access that accepts a unauthenticated requests and performs this task directly in Cognito User Pool.
I am creating a saas, software as a service site with django.
Due to the project requirements the users are inside schemas/tenants, for that im using the fantastic django-tenant-schemas app, one user can have accounts inside different schemas (they share username and password) ... i want to let the user move throught the different schemas they are in more or less freely ... for that i have created a view where the user can select on what schema he wants to be on.
When i use an application wide cookie session that is when i have the cookie setting as ".domain.ext" (django documentation) that works fine but its NOT the behaviour we really want for our application.
What we really need is to be able to have different versions of the app on different browser tabs.
So we have to set the cookie configuration to "domain.ext", then everything breaks because the original view is on one tenant and the next view (where the just logged user really belongs) is inside other tenant then the old cookie is deleted.
So the question is how can i programmatically set the cookie correctly on the new view so the user that really belongs to that tenat is still authenticated.
Or is there any alternative approach we could use for that? Any examples?
EDIT TO CLARIFY as demanded:
Person A belongs to 2 schemas SH1 and SH2 on both of them he has the same username and password.
On every password change the password hash is replicated on all the schemas they belong to so they dont have to remember specific passwords or usernames.
When the person is logged on SH1 the url will be sh1.domain.com when he is logged on SH2 the url will be sh2.domain.com
So lets say the person is now logged on schema SH1, he decides to switch to schema SH2, to be able to do that i need the user to still been authenticated so that view has to be on the SH1 schema, but then its redirected to the new schema force authenticating the user but since the cookie is set as domain specific (default django behaviour) when the user lands on the next url sh1.domain.com/whatever the previous cookie is deleted and thus he has to log in again to be able to access.
If I'm understanding correctly, you want the ability to have the behavior of a cross-domain cookie, but without actually using a cross-domain cookie.
The immediate answer that comes to mind is "well, use a cross-domain cookie". This is pretty much the vanilla example of a situation where you'd want to use use a cross-domain cookie. Engineering a complex solution so that you can avoid using the simple solution never ends well :-) Unless there's some other constraint in play that you haven't revealed, I'd start by questioning whether you shouldn't just be doing this the easy way.
However, assuming there is a good reason (and, frankly, I'd be interested to know what that is), the problem you're going to face is that browser security is essentially trying to stop you doing exactly what you're proposing. You want to know, from domain SH2, whether something has happened to a cookie set on domain SH1. That's exactly the situation that cookie security policies are designed to prevent.
The only way you're going to be able to work around this is to have a third party that can share knowledge. When user A logs into SH1, you do password authentication as normal - but you also post a flag somewhere that says "User A is now on SH1". When A logs into SH2, you post the corresponding flag. If A goes back to SH1, you check against the central source of truth, discover that they're currently on SH2, and force a login.
You probably could do this by manipulating cookies and session keys, but I suspect an easier way would be to use an Authentication backend. What you'll be writing is an authentication backend that is very similar to Django's own backend - except that it will be making checks of cross-domain login status against the central source of truth.
How you implement that "source of truth" is up to you - an in memory cache, database table, or any other source of data will do. The key idea is that you're not trying to rewrite cookies so that the same cookie works on every site - you're keeping each site's cookies independent, but using Django's authentication infrastructure to keep the cookies synchronised as a user moves between domains.
I'm using django-auth with the django-auth-openid extension to use OpenID (specifically, Google) to log users into my site. I have a user base of about 90 who will be using the site. All of them have Google accounts, and will be using them to access the site. Since the user base is set (there is no registration allowed, only admins can add users), I already have an exhaustive list of all of my users, including their email addresses and other information. How can I allow these users to login with their Gmail addresses without making them register first? Essentially, I'd like to make django-auth-openid match OpenID Gmail addresses to rows in the existing django-auth Users table. Is this possible?
Thanks!
I ended up using the python-social-auth library (which has Django support built in). The documentation for use with Django isn't great, but between the docs and the provided example it was relatively easy to integrate it with my existing django-auth setup. After that, I just deleted the 'create_user' pipeline from the SOCIAL_AUTH_PIPELINE tuple in my settings, and, that way, only users with existing OpenID connections were allowed in (no new registrations occurred from OpenID logins). This meant, though, that I had to create those connections (between OpenID identifiers and Users) manually, but that was pretty easy to do just using the Django Python shell.