Assume that client X uses role based authorization and the client identity is provided by any OpenID Connect provider (e.g. microsoft). User logs in client app and client X wants to authorize user access to e.g. admin page with role. Should client app have some store (e.g. database) where user roles are associated with their subjects received from id_token, or identity provider should do it?
The approach where the client does it seems better to me. If authorization server would handle e.g. 100 clients where any client has it's own roles, I think it's not efficent but some identity providers do it.
So what would be good solution to handle role based authorization using some OpenID Connect server as identity provider?
Related
I have a web application that is leveraging Keycloak for IdM.
I am using the Resource Owner Password Credentials or Direct Grant flow for authentication which uses REST API calls to /auth/realms/{realm}/protocol/openid-connect/token instead of browser redirects to get the user a JWT.
I would like to implement a similar workflow for signing users up.
Looking at the Keycloak documentation it appears the Keycloak Admin API exposes an endpoint for this at /auth/admin/realms/{realm}/users.
To allow clients to interact with the Keycloak Admin API you have to create a client service account and associate it with a keycloak role with sufficient privilege to manage realm users.
The expected approach for this seems to be to apply the manage-users realm specific role to the client service account. This is more permissions than I would like to grant to the client.
Is there a way to grant a client service account just the ability to create new users and not the full set of permissions that comes with manage-users?
We are setting up an Identity Server 4 instance and one of the GrantTypes we wish to use is the Client Credentials Grant Type.
Is there a way we can link Client Credentials up to a use an AspNetIdentity user so we can get the claims and users details back for the client credentials provided?
Thanks in Advance
The Client Credentials grant type does not represent a user, it represents an application, so you would not use AspNetIdentity with the client credentials grant type.
If you want to include user specific claims you need to look at one of the grant types which involves user authentication. Examples are available in the quickstarts here. I would advise looking first at the Resource Owner flow and then the OpenID Connect based flows.
The quickstarts also include an example of integration with ASP.Net Identity, that can be seen here
I am working on a server with a legacy user set and user roles. The server exposes a REST API which use a gross set of roles to authenticate with.
The owners now want to move to a new authentication scheme and OpenID Connect seems like a good fit, due to there being a requirement to identify users. Also the authentication server has to run in a cluster ( there's reasons! )
My question is, is it possible to sync the existing roles on the server to an OpenID container so that any client asking for access to those roles can be authenticated?
I am trying a POC with WSO2 API manager and Identity server. The application users are registered to the user store on the identity server. An API is exposed on the API manager that will be used by the application. The goal is to authenticate the users accessing the application using the oauth resource owner password credentials. The user credentials are in the user store on the identity server.I created a new tenant for this.
I configured SSO for the API manager by using this documentation. so that the users are authenticated against the identity server user store.
Tried to generate a token to access the API exposed on the API manager. I was able to retrieve the token client credentials grant type but not for the resource owner password grant type.
Appreciate any help here.
I do not think, you need SSO here. SSO is needed with APIM and WSO2IS, if users need to login to the API store/publisher/APIM management console. I hope you are talking about end users.. Then end users are may not need to login to the APIM. They just need to login your custom applications and application would call the APIs in the APIM.
But, say user need to login to custom applications using SSO, then you can configure SSO between WSO2IS and custom applications. Please refer here. Once user login to the application, application can exchange a end user's SAML2 Assertion with access token by using APIM. Then application can access the APIs in APIM using access token behalf of the user. You can refer this for more details
Also, if you are just trying to use OAuth just for authentication, You may need to use openid-connect. (just to login to custom application)
I'm working on an OAuth 2.0 server to support multiple clients and roles.
Let's say I have an API server that requires an access token from an OAuth server.
These workflow I came up with. I have three serves for this simple workflow -- OAuth, Client, and API server.
Users on each clients have email and password (these credentials are stored on OAuth server)
Users sign-in with their email and password on their clients then the clients send the credentials to the OAuth server for authentication.
OAuth server checks the credentials and issue an access token.
When a user requests an request to an API server, API server talks to OAuth server to see if the user has access to the resource. If so, perform requested request then return something.
This is somewhat unusual workflow in my opinion. The reason I want to do this way is because we actually store user credentials on our OAuth server. I also have multiple roles (groups) for each clients.
Is this OKAY workaround or is there a better way for one OAuth + multiple clients and multiple roles?
What you describe is the equivalent of the Resource Owner Password Credentials grant in OAuth 2.0, see: https://www.rfc-editor.org/rfc/rfc6749#section-1.3.3. You should be able to do this with a stock OAuth 2.0 Authorization Server that supports this grant. So it is not unusual or proprietary but requires a great deal of trust in the client because it "sees" the password.
You can model multiple roles and groups by representing them as different "scopes" that are associated with access tokens and thus clients.