In UAA There are two Concepts, Authority and Scope.
These concepts seems to overlap. I would like to know exact difference and purpose
For example , oauth.login
Scopes are permissions of an OAuth Client acting on behalf of a User. They are granted after obtaining a user token with one of the following grant types: auth_code, password, implicit. Scopes signify what the application is allowed to access on User's behalf (referred to as delegated authorisation).
Authorities are permissions of an OAuth Client acting on its own behalf and there is no User involvement. They are granted after obtaining a client token with grant_type of client_credentials. Typical use is an Application or API trying to access a resource with its own credentials without user involvement.
In UAA , oauth.login is a system level permission and was being used by the legacy implementation of the login-server project (When UAA and Login Server were separate components). This permission allows admin level access for login server.
1) authorities and roles are spring-security wording for permissions. It is not defined in OAuth2 specs.
2) scopes are defined by OAuth2. It is intended to define what the end-user allowed each client to do on its behalf (information from authorization-server to resource-servers).
As a consequence, authorities granted to a client should always be a subset of end-user ones : all possible scopes => all of user authorities ; the less scopes, the less authorites.
One trick, on "client" OAuth2 flow, the client is the end-user => scopes make no sense in that case (the client is not authenticating on behalf of someone, but in its own name).
Default OAuth2 spring-security converters turn scopes into authorities. To me this introduces a lot of confusion and should not happen. Scope claim should instead be used to filter end-user authorities.
Latest requires to write and configure your own authorities converter which is already possible for JWT but not yet for introspection (should come, a ticket is opened for that)
Also, nothing in OAuth2 specs requires permissions (spring authorities and roles) to be contained (using a private claim) in the token or managed by the authorization-server. It is legit for a resource server to retrieve it for instance from a database using the subject claim and then "scope" it (filter end-user authorities according to the scopes granted to the client).
Related
I have an endpoint, which I want to protect using Oauth2 and spring boot. The users register on the website and after the successful payment, a token with specific expiry should be issued automatically and delivered to the user. The User can revoke the token in their panel and get a new token manually.
I don't want to use password grant type as it requires sending the username and password for each request. the authorization code grant type, requires the user to enter their credentials which doesn't fit my need for automatic generation of tokens after successful payment. I'm not sure if using client credentials grant type is a good idea for my need. I could use a new client for each new user. But this seems not right to me. But correct me if I'm wrong. any idea which oauth flow I should use?
You want to authenticate end-users with OAuth2? Use authorization-code (with PKCE).
In your statements, there seem to be a confusion between authorization-server (issues tokens) and resource-server (subscriptions are resources too in my opinion). Have a look at this article for OAuth2 refresher and spring resource-server security conf.
Also, it seems to be a one-to-one relation between access-token and payed subscription. This is probably a mistake: access-token should be short lived (like a few minutes). Are your subscriptions that short?
I see two options here:
have your authorization-server add a private claim with subscription status to JWT access-token (or introspection details) and check this claim value in spring-security expressions (#PreAuthorize("..."))
configure a custom authentication converter in spring security which calls a #Repository to read subscription status in database, based on identity contained in access-token
First solution is way more efficient (persisted subscription status is retrieved from DB only when a new access-token is issued) but requires your authorization-server to be flexible enough for you to add private claim with values from a web-service or a DB. I have a tutorial to do so in Keycloak. read it AFTER the article above.
I was getting started with Spring Boot and Angular 7 and I came across user authentication.
Let's assume the following: I have a frontend with Angular 7 and a Backend with Spring Boot that offers API's that can be accessed via HTTP.
So I know that usually the frontend authenticates the user with e.g. JWT that stores all necessary information about the user that might be needed. But I came across the SecurityContextHoler of Spring Boot Security:
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
This allows me to simply access granted Authorities and so on. So I thought about the following:
Using JWT for the frontend grants the following advantages (as far as I know):
* Users can identify when using API's
* Users may be prevented from certain UI-Elements (based on roles stored in JWT)
* Modification prevention due to checksum (invalid token afterwards)
Now I could also add a check in my Controller in the Backend that checks the SecurityContextHolder for user permission (something like a Service that checks the current context permissions vs the needed permission and returns true/false). Wouldn't that be even more save, since it is in the backend (so in my inmagination everything that runs server-sided is always a little more save than what runs client-sided)?
I can store information in the frontend (like roles and a username) to use them for the UI-based-access prevention to still have the same advantages as JWT provides, but I do not have the "effort" of implementing the JWT creation.
But obviously it is not common to do it that way (at least I never saw it), so what is the advantage of the Tokenization?
They are not mutually exclusive. You would use what you call "Tokenized Authentication", like an oAuth2 Bearer token most likely in a JWT when the Authentication is performed by a separate system from your Spring Boot backend. For example, you may be using Okta, Keycloak, Google or Facebook to authenticate the user.
At a minimum, your Spring Boot backend stores the username extracted from the JWT in the Authentication. You can get Spring Boot to extract any roles in the token and add those to Authentication::grantedAuthorites. If your backend system, has it's own set of roles in addition to what's in the token, then the backend could implement a PrincipalExtractor to load a UserDetails object for this user from the database as the Principal and merge the roles in the token with those store in the local database.
You'll probably want to security certain methods in your backend with method security annotations like #PreAuthorize(), since you shouldn't trust the front end. The method security will check permissions, like hasRole("ADMIN") or hasPermission(object, 'READ') using the Principal object in SecurityContextHolder.getContext().getAuthentication();
In the end, the token assures the backend the user accessing it is who they say they are, i.e. Authentication, but does not necessarily tell the backend what they are Authorized to do. Yes, if you control the Authentication server you can include roles in the JWT, but roles don't usually provide as fine a grained control as is required.
Independent of what level of security you implement, the token is translated into an Authorization so you can use the Spring Security framework to manage access within your backend code.
There are 3 type of token in spring security OAuth2:
1. InMemory token Store
2.JWT token store
3.JDBC token store
So now you’re talking the JWT token store. The most powerful of JWT token store is prevent the authorization server load against to the database for checking such as role,token expired so it is related database load performance. Since all the information such as: role,username, token expire ,etc include in token itself. So the authorization server or other resource sever may using the public key to verify this token itself without invoke to data store.
Hope helpful! ☺️
As I understand before messing with Laravel Passport, password grant type is resource owner type and client_credential is for first party app, so basically routes protected with client_credential can access with token issues by itself,
My problem is token issued from password grant type can access routes protected by client_credential, and routes protected by api:auth can't be access by client_credential token
These are two different flow types.
First you need to understand the different between client and resource owner. This is explained clearly on roles section of the protocol.
resource server
The server hosting the protected resources, capable of accepting and
responding to protected resource requests using access tokens.
client
An application making protected resource requests on behalf of the
resource owner and with its authorization.
Now, the flows you have mentioned use credentials from resource owner and client. The clients in client credential flow are confidential clients. That means they have a client secret with them.
In resource owner password grant, you obtain tokens from token endpoint by presenting resource owner credentials. For client credential grant type, you obtain tokens from token endpoint by presenting client credentials. So as you can see they are two different flows.
Depending on the implementation, tokens issued for these flows could have different scopes. That mean, those tokens may have a different validity or could have limitations. Such restrictions are independent of OAuth 2.0 protocol.
After configuring two UAA instances as federated, say UAA1 (Relying party)--uses--> UAA2(ID provider) through OIDC mechanism, I can use UAA1 to authenticate users defined on UAA2 through authentication code work flow. UAA1 defines shadow users in its instance, but it does not capture groups defined for users on UAA2.
For example, user1_uaa2 is on UAA2 and it belongs to a groups called uaa.test. After login through UAA1, a shadow user user1_uaa2 is created in UAA1, but its group information is lost.
How can a user's group information be propagated back to relying party in OIDC based UAA federation?
Thanks
I think according to source code, that in last version of UAA (V4.10), UAA only returns openid as scope in id_token and /userinfo, no matter if the access token has roles scope or not. That means as either OIDC or SAML identity provider, it does not provide user group information.
It seems to me its codes work and are able to retrieve group information when UAA works as SP or proxy to other IDPs. It store those information to user_info table.
We have to configure a time limited access per user and per client in keycloak. E.g. User a should have access to confluence from 2017-11-06 until 2018-11-06.
We configured a time-based policy in the keycloak admin console and checked sucessfully the conditions with the built-in evaltation page.
Clients >> Confluence >> Authorization >> Policies
But keycloak didn't evaluate the policies during the login of the user.
Our first assumption was that keycloak sould evaluate these policies while user authentication, but none of the policies we configured had any impact to the user authentication (The user can login independent of the policy configuration of the keycloak). We assumed that the client (e.g. Confluence) has to evluate the client policies. Is our assumption correct?
Please could you be so kind to give us hint how to configure user access policies in keycloak that will be evaluate during the user authentication?
The policies are all about authorization only!
They have no impact on authentication.
Authentication is just the verification of the login credentials.
Keycloak itself is not making any authorization decision. It just provides data, such as claims, roles and permissions that can be used by a client (i.e. application) to make authorization decisions.
Depending on the defined policies an authenticated user has specific roles and permissions in the corresponding access token.
The application then is responsible to allow or deny access for specific functionality or data based on the user's provided roles and permissions in the token.
That is, the policy you described will influence the permissions of the user. Before 2017-11-06 and after 2018-11-06 some required permissions will not be in the user's access token and therefore access to some functionality will be denied by the application.
Sorry, but I have no idea how this works in Confluence.