We use keycloak as IAM solution. We have several customers who need access to certain products. Is the information on which product the user is allowed to access stored in the keycloak system or do I have to store the information elsewhere? My fear is that if I store 1000 productIds in the user token the will be very large and must send again and again to the server.
Related
Iam working on a flutter mobile application where i use Google SignIn for Auth, is there a way to authorize users with existing account only?
Prevent users from creating new accounts? I've looked for the same thing without finding a way to do this with any Firebase project setting.
The solution, I believe, is consider the difference between authentication and authorization. Firebase's Authentication service is aptly named. It does authentication
- validates that a user is actually who they claim to be. It does not do authorization - control what actions authenticated users are allowed to perform or what data they can access within an application. App developers have to be responsible for managing user authorization.
One way to do this is to maintain a collection of "authorized users" in Firestore, for example. When a user authenticates, your app would perform a lookup to see if the current user is actually authorized or not. Security rules can be written for Firestore and Firebase Cloud Storage to also validate that the current user is in the "authorized users" collection before allowing access to data. But this requires extra data queries to obtain this authorization info.
The authorization method I prefer is to use Custom Claims which can be assigned using the Firebase Admin library. A custom claim can be added to an existing user account that can act as a flag indicating what type of authorization they're granted. Front-end code can check the authentication token they've been issued for the custom claim to determine the authorization they've been granted. Server-side code and security rules can also check for those required custom claims within submitted requests.
Realistically, any application you build where different users might have different levels of access will require you to deal with authorization. I believe that assigning carefully thought-out custom claims is the best solution.
I am building a SPA with a spring on the backend. I am working on signing in with Google, most of it is working already: got the id_token with the implicit flow in the frontend and I sent it and verified it on the backend.
I want to have users with roles and manage that locally (so, no adding info in the oidc provider). What are the options to go from the id_token to having an authenticated user in spring? I did not find any example doing that link manually (id_token-spring_sec_user).
I have checked several sources like the Spring Security 5 presentation at SpringOne https://www.youtube.com/watch?v=WhrOCurxFWU, several SO questions and posts on okta's and auth0's blogs but I am still missing the link.
You will have to create your own (application) specific roles.
Use these steps :
Get authenticated from Google
Access the profile section from google (username, name etc )
Use your own user table to store this info
Create admin APIs in your own system and assign your app-specific roles to the user.
When you login again you will authenticate against google login/password and roles specific to your application .
Create an account or session with the id_token
Check if the user is already in your user database. If so, establish an authenticated session for the user. If the user isn't yet in your user database, create a new user record with default role from the information in the ID token payload, and establish a session for the user. You can prompt the user for any additional profile information you require when you detect a newly created user in your app.
Here is how my application should work:
Users can use some functionalities of my application if they have enough chips (token) which they can buy from another application, or they can be granted to them upon some event, whatever.
Users have an attribute associated with them called 'chip', which represents some number. This information should be represented as a claim, probably.
I want Keycloak to do this authorization for me - to check whether user can use the functionality or not. I've come across JavaScript-based policies. It's seems they are able to operate on informations in tokens - like user email etc, but this is not my case where token can contain obsolete information, i.e. when token was generated user had enough chips but since then he spent them.
Maybe token should be refreshed upon spending chips, but in that case, would it be updated with current informations bound to user? Or maybe authorization service can somehow access database during evaluation of a policy? Could this work or are there any elegant solutions to this use case?
Keycloak is not here to check if the user has enough money. Keycloak is here to say if the user is authenticated and if he has the roles for a certain application (admin, user...).
Checking if the user has enough money should be on server-side. For an incoming request, you have to check in the database if the user has enough chips to access the application and if he hasn't you return 403.
I am working to build an application which would be able to create custom audiences for many of our clients for facebook ads. I came to know that the most suitable access token for this purpose is system user token (correct me if I am wrong). To get regular user access tokens, we can make a user go through the traditional oAuth flow, I am looking for something similar to get system user access token. How can I get it for any of my clients? Thanks
You must create your system users in the Business Manager of your company:
https://business.facebook.com/settings/system-users?business_id=<YOUR_BUSINESS_ID>
Once you create a system user, you can generate a token for him associated with a given app.
Meanwhile, on your business settings (as stated in the docs) you can request access to an ad_account.
Request Access to an Ad Account: If you request access to an ad
account in Business Manager, the admin of that Business Manager can
grant you permission to work on it.
Once your client gives your Business permission to work with one or more of their ad_accounts, those ad_accounts will appear in your Business Manager. (menu on the left).
At that point, when checking the profile of your system users, you can click on assign assets to give the system user access to pages and ad_accounts.
The token you generated for the pair [system_user,app_id] does not need to be reissued to reflect the addition of assets to which the system_user has access.
I am designing a simple REST API with Stormpath Facebook integration and wondering what would be the best pattern for user authentication. Currently I do not have any endpoint for user creation, so all requests to my endpoints are authenticated like this:
Get Stormpath Application object based on API_ID and API_SECRET configured in my app
Get Stormpath Account object based on Facebook token specified in every request
Based on account status authenticate request or reject
This follows more or less official guide and works fine because even though user account does not exist it will be created upon first get account request to Stormpath. Does it make sense and is it safe enough? I was looking for some documentation or best practices but could not find anything.
I would also need to get / generate unique user ID so I can make some relations with user data in my system - so another question, what is the best approach here:
Generate some unique ID, associate it with user email got from Stormpath and save in my system - I think this violates a little bit idea of such a service like Stormapth which encapsulates all user data
Do the same as above but store it in Stormpath Account customData
Use Stormapth user resource ID which can be obtained from user URI
Please advice.
Just for the record I am using Stormpath Java SDK and designing the API to be a backend for mobile social app so security is quite important for me.
Full disclosure, I manage Product # Stormpath. I'll be using your feedback to enhance the documentation.
It is hard to say if it is safe or not, without understanding the REST API you are building. If you made a REST API for cat pictures, my answer would be different compared to medical / financial information. One way to look at it, is that Facebook has the Graph API (REST) and they protect access requiring the same access token you are using. There are other flags that would cause me to say it isn't safe, like if you were using HTTP with no TLS.
To your second question, how to link Stormpath with your data. I wouldn't say you would violate anything about Stormpath by modeling out your application that makes sense to you and your app. Stormpath has customers that store EVERYTHING about their users in Stormpath. Stormpath also has customers that use Stormpath solely for authentication and authorization data and use customData to draw the link between a Stormpath user account and their data.
How / where you store the information is based on your needs. If you are starting with authenticating the user account with Stormpath, it would make sense to put the unique identifier / primary key in the user account's customData. If you are starting with querying your data store for the user data and need to get the Stormpath user account, then you will need to store the href for the user account in your data store.
A nice feature in the Stormpath SDK for Java is that when you do authenticate with Facebook, the returned object will disclose if the account was newly created or if Stormpath has existing account for the access token:
https://docs.stormpath.com/java/apidocs/com/stormpath/sdk/provider/ProviderAccountResult.html
This means that you will know when you need to create a record for the account in your data store and connect the two using customData and/or the user account href.