I need a suggestion on how to perform this. I'm using the Keycloak API to perform requests like retrieve users, groups, or other CRUD operations. All these ops can be done with the admin account; what if I would a user, using its own access token, to access only to its own information? Is there a specific endpoint I haven't seen in the documentation or is there a workaround?
Thanks in advance!
By postman:
{{yourKeycloakServer}}/auth/realms/{{yourRealm}}/protocol/openid-connect/userinfo
with accesstoken and POST method.
I don't know about any specific endpoint to see only user's own metadata, but it is possible to create a new user in Master realm and restrict it's access to Admin API.
For example, we can grant to that user only certain roles like View/Manage Users of only one specific Realm. This way we don't need to use server's primary admin account.
Related
My express.js backend has an endpoint which returns a list of what data the user is authorized to view. There are Auth0 roles corresponding to which segments of this data any given user is allowed to read. A user may have any number of these roles. However, when I tried to add role-based permissions to this endpoint, I realized that the Auth0 recommended middleware express-jwt-authz perhaps doesn't do what I intend: it simply authorizes/rejects based on the roles in the JWT. This endpoint only requires a user's session authorization, not the user's roles.
I want the endpoint to change its responses based on which Auth0 roles are associated with a user. The only solution I can think of is adding a row to my own database (which is not connected with Auth0) where I keep track of each user by the JWT sub property, and manage their roles/permissions from my backend. However, this seems like it would split roles between Auth0 and my application's database, and furthermore feels one step closer to rolling my own authentication system, which I do not want right now. Is there a way I can do this with Auth0 and express.js?
I was able to work around this by selecting "Add Permissions in the Access Token" in Auth0 in Applications > APIs > [my API] > Settings. Then I could view the permissions passed into req.user.permissions on my backend, and process them how I wanted there.
I'm new to wso2 and there are many new concepts to me ... I'm looking for a yes/no answer to the following question:
With wso2is, is it possible to authenticate users using one secondary user store (AD / LDAP) and authorize them using another secondary user store (JDBC, a database with only user and role tables)?
If the answer to the question is "yes", can you please provide me some links to some related examples or documents?
Any suggestions?
Thanks.
Yes, its possible. we can use different user stores.
Please refer
https://docs.wso2.com/display/IS530/Architecture
https://docs.wso2.com/display/IS530/Configuring+Single+Sign-On
Yes!! it is possible. Write your own custom UserStore and overwrite the method getting claims from user store.
Google it and you will find steps to do that.
I plan to use IdentityServer 4 on ASP.NET Core with ASP.NET Identity as the data store. This is the first time I use a central authentication/authorization and I am wondering how to solve the following question:
Assume I have users with claims like name, role etc. and a Web API (scope) that allows these users access to measured values from hardware devices. IdentityServer will allow me to authenticate known users but now I need an access control that knows which users may access which device data.
Where do I store this information? Since it is specific to the scope I guess it should not be stored in the IdentityServers store. On the other hand, if I store it in the scopes own database I somehow need to connect it to the users defined in the IdentityServers store. Should I define user IDs that are unique to all scopes and IdentityServer?
You will need to correlate the User Ids that IdentiyServer returns with users defined in the scope's database.
I believe that there is a User table and a UserLogin table where you could track the different logins for each of your users.
Then, in the scope's database, you can then specify which users have access to what device data.
This is a bad idea and will probably lead you down a road that you should not.
This means that your client application requesting the scopes will need to know which user has access to which scopes even before requesting a token from your IDP (otherwise your token request will not work). Rather model these as user claims. Then on your WebApi you can do normal claim based authorization.
I need to get logged in user's ID on a web page where user is authenticated via OneLogin. We need to use OneLogin's REST API endpoint that can give me logged in user's details.
https://api.domainname.onelogin.com/api/1/users/:id
For above REST API I need user's ID.
Can you please help me figure this out?
Are you saying the user has a OneLogin session? Or that you are using the API to authenticate the user using the delegated authentication API?
If you are using this: https://developers.onelogin.com/api-docs/1/users/create-session-login-token
The user ID is in the response.
If the application you're writing supports SAML then part of the SAML assertion you got from OneLogin should be a unique user attribute (email or username)
Your best bet is then to get that user from OneLogin by using that attribute -
https://api.<us_or_eu>.onelogin.com/api/1/users?email=user#test.com
or
https://api.<us_or_eu>.onelogin.com/api/1/users?username=testuser
And since that value is unique, it will only return the one matching record (i.e. The current user)
If I'm using JWT to authenticate users to get access to my API, would it be possible to create one "generic" account for many users to use? That way, users who don't have a "real" account, would be given this generic account credentials in order to access the API. Would that be possible? Because, I'm wondering, with JWT, if one users log in, would I invalidate the other user token?
If that approach would not work, what would you recommend?
The reason: I want my app to communicate with my server, even if the user doesn't have an account created. But I would not like to keep that "door" open, hence I would like to add some kind of authentication for those people who are using the app but don't have an account. Suggestions?
Create accounts connected with accountgroups. This way you are also able to create temporary accounts having less permissions for example. And multiple clients are able to access same data and same time.
So the Payload is owned by the accountgroup, the client authenticates with a (maybe temporary) account and gets authorization via accountgroup.