We are using auth0 for authentication and also for simple authorization.
We would like to extend our permission system to allow us to assign certain rights for different applications per project.
User
Project
Permission
auth0-001
000001
application1:x:read, application1:y:create, application2:x:read
auth0-001
000002
application1:x:read
auth0-002
000003
application1:x:read, application2:y:create
I don't see any chance to map something like this in auth0.
If I add every project-permission, the JWT is way too large.
Our alternatives are to distribute the information asynchronously via pub/sub.
But then every service needs to consume these topics.
Do you know software or have an idea how you could implement something like that?
Related
Hi I'm having issues security my application, enabling authenticated users access to specific endpoints, non-authenticated users access to others and most importantly, continuing to enable the application to communicate with itself, without storing passwords as a String in the case base.
The code base:
My code base consists of numerous packages that communicate via REST and GraphQL calls. With no authentication, this system works fine. Development is in Java 8 with Maven.
Aim:
I am currently in the process of adding authentication to the code base which should enable three things to occur.
The different projects in the application continue to communicate easily.
An "admin" user can log in and make calls either via Swagger or GraphiQL or any methods they require.
The average user will only be able to access specific endpoints such as UI elements (e.g. localhost:8082/user-ui [unique_key])
Current Development:
I've implemented Spring Security In-Memory Authentication (https://www.appsdeveloperblog.com/spring-security-in-memory-authentication/). Which successfully blocks URLs being called and prompts the user for credentials, except on certain predefined endpoints. This fulfilling criteria 3 and part of criteria 2 (as the Admin can access Swagger and GraphiQL).
My Problem:
Unfortunately setting up this system has broken the internal calls as the RestTemplate used to communicate between packages no longer has the correct authentication.
While I could use BasicAuthenticationInterceptor(https://www.baeldung.com/how-to-use-resttemplate-with-basic-authentication-in-spring) to provide the authorization, this would mean having to write the password in a String in the code base. As I understand it, this is bad form as the String is then stored in the String pool. Elsewhere I've managed to avoid this using the CharBuffer before encoding the password, however BasicAuthenticationInterceptorrequires a String.
Any advice on how to proceed would be greatly appreciated.
If you are using basic authentication, you will have to provide the password when you are making internal calls with resttemplate. That doesn't mean you need to store the sensitive data (in this case credentials for your basic authentication) in plain text in the code base. One of the most common practices is to use an external file to store the sensitive data and then get the application to use them at run time. You may also want to ignore that file from git repository to prevent that being part of the code base.
If you are using Spring boot have a look at the environment specific properties files, which could be an ideal way to store profile specific configuration and data like these.
https://docs.spring.io/spring-boot/docs/1.5.5.RELEASE/reference/html/boot-features-external-config.html
https://www.baeldung.com/properties-with-spring
If you are worried about storing the credentials in plain text in properties file, you can also encrypt sensitive data in your properties files.
Spring Boot how to hide passwords in properties file
I have been trying to implement an authorisation scenario in my loopback architecture, I am well aware of the default authorisation that is being provided by loopback, but I'm using auth0 as my user management platform.
I am having user type in the auth0 metadata and now I want to allow certain HTTP methods on those particular loopback entities based on the attribute in the user object.
There might also be scenarios where for certain users I will have to hide a few properties of a model while open them up and show in case of others. If there is any other framework that might serve my purpose I am happy to restructure the whole system. Any suggestions would be helpful.
Im currently working on a nodejs project and require some authentication. As it stands I just use expresses basicAuth function, however I can't seem to figure out how to do more advanced operations. For example I have two url parameters say bob and steve. If the user navigates to website.com/bob I want it to ask for username:"user" and password:"password". However if the user navigates to website.com/steve I want it to ask for username:"user2" and password:"password123"
Would this be possible using basicAuth and if so how? Or would something like passportjs be able to accomplish this task? I dont need an amazing solution just something to stop people accessing certain areas.
What you are trying to achieve is probably access control and I suggest you use a access control list module which will allow you to implement policies as to which users/groups have access to which resources within your application.
This way, even if a user provides their username/password pair, they will not be allowed to access that resource based on the policy which is a better option application design wise.
For a start:
https://www.npmjs.org/package/acl
Im using GWT, GAE to make a web app.
I looked at a bunch of tutorials regarding implementing a login system but most of those tutorials implement it so it's mandatory to login to access the web app. How would I go about making it so that anyone can access the app but if they want to use account specific functionality, they they have the option of signing up for an account.
There are two parts to it.
First, in your client code you check if a user is logged in. If so, you allow access to the "closed" parts of the app. If not, you show a link/button to login and hide tabs/views that are accessible to authorized users.
Second, in your server code you specify which requests do not require authentication and which do require it. This is necessary if a user somehow figures out how to send a request without using your client code.
For example, in my code some requests have checkSession() called at the very beginning. If no authentication object is found for this user in session, this method throws LoginException to the client. If the authentication object is present, the request continues to execute normally and returns requested data to the client.
Further to Andrei's answer, if you want a framework to manage the sessions for you, you can use GWT-Platform, which has an excellent Gatekeeper feature.
I use it for mine and I have a LoggedInGatekeeper class. Simply add #UseGatekeeper(LoggedInGatekeeper.class) to the constructor of each presenter proxy and it checks if the user is logged in. If you want anyone to be able to access that page simply annotate with #NoGatekeeper. Easy!
It takes a bit of setting up but it's a great MVP framework. There are maven archetypes and samples etc.
Hope this helps.
We have a web-app which uses federated authentication to authenticate users. Data for the Fed Auth are obtained from the Active Directory service.
One of the system's requirements is to have a "Last log in date" saved in the web-app, but the application is not performing any log in operation. It just checks if the incoming request if allowed to perform requested operation, based on the AD credentials.
Have you ever encountered such a requirement in a similar scenario? What was your approach to the problem? We thought about creating user session on the first request and treat the session creation point as the log in date. This seemed as a bad idea, as we don't want to use user-session at all, and it would be the only scenario utilizing it.
Another approach we were thinking about was to use client to tell us if he is logging in or not, for example by making a special "mock" request, which on the web-app would be treated as the log in. This also seems bad, because in that case we have to trust the client to be telling the truth, which basically looks like a major vulnerability.
I am aware that this requirement makes little sense in such environment, but that is something I can't argue with right now, that's why I am trying to find most reasonable solution to that situation.
Thanks for all the suggestions in advance.