I have an Auth0 project that I am using for authentication. I have modeled my Spring code based on this example.
I am trying to limit an area like this...
.antMatchers(ADMIN).hasRole(Role.ADMIN.getRoleName())
But when I add my Admin role to my user and try to log back in the JWT does not show any roles when I run...
Collection<SimpleGrantedAuthority> authorities = (Collection<SimpleGrantedAuthority>) SecurityContextHolder.getContext().getAuthentication().getAuthorities();
It is empty. How do I pass the roles to my application using Auth0
More Information
I tried decoding the JWT token and I don't see the role information even being passed....
Header
{"typ":"JWT","alg":"RS256","kid":"<Removed>"}
Body
{"iss":<Removed>,"sub":<Removed>,"aud":<removed>,"iat":<removed>,"exp":<removed>}
So why is Auth0 not passing this information.
Groups, roles and permissions won't be added to the jwt automatically. You have to
create a new rule or modify the default rule which is created after enabling (publishing) the authorization extension.
Adding roles and permissions to a JWT access token in Auth0
You should provide the granted authorities to your principal when you're authenticating it.
I assume you have a custom class that implements UserDetails and you overwrite getAuthorities(). This method should return an authority called ROLE_ADMIN. Notice that the role should be prefixed with ROLE_
Related
We are using Okta as a OAuth login provider.
What we wish to achieve is to fetch user role information in the authentication response itself. We are using spring security.
Currently we get following details in org.springframework.security.oauth2.core.oidc.user.OidcUser object
[Edit]
Adding content of authorities
This does not include user role information. Is there a way to get the user role information in the authentication response itself?
I'm currently using OAuth with the password grant type to manage the security of my Spring Boot application. Now I want to store a login id which is queried by the auth server from the database when the client has successfully requested an access token.
To realize this I thought of passing it with the JWT. I used a custom TokenEnhancer in combination with a TokenChain to add the additional login id, which works fine. My problem is that I couldn't find a way, other than parsing the token myself, to get that login id.
Another, but a very bad solution could be to just pass it as authority.
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).
I am using a custom UsernamePasswordAuthenticationFilter (which is called before the login page). I am considering the session id of the already logged in user in this filter. If the auth_token exists for the corresponding session id I want to bypass the login page.
How can I do that ?.
You just have to populate the security context with an authenticated Authencation once you have checked the auth_token. Something like that (in your custom filter):
... // first check the existence of the auth_token and extract some information from it like user name and roles
String login = ...
String role = ...
PreAuthenticatedAuthenticationToken preAuthenticatedAuthenticationToken
= new PreAuthenticatedAuthenticationToken(login, auth_token, Collections.singleton(new SimpleGrantedAuthority(role)));
SecurityContextHolder.getContext().setAuthentication(preAuthenticatedAuthenticationToken);
//At this point : the security context contains an authenticated Authentication and other security filters won't have any impact anymore
I don't say it is the best approach for your needs, but it will works with a more or less standard spring security configuration.
so I am trying to secure a web application that I built using spring mvc and security. I currently have the basic username and password from a normal custom login page working using a custom authentication provider to provide the populated authentication object that is verified against a database. What I am wondering is how do I implement a second phase of logging in that uses TOTP? I can get the the TOTP issuing and verification to work, but am unsure how to modify spring security to accept a change to authorization via a form submission of the token on a page other then the login page I've specified.
So basically what I ended up doing was using the authy api(http://docs.authy.com/) to do the TOTP delivery and verification. After the initial login I grant them ROLE_PRE_AUTH and then send them to a protected page to process the TOTP. I then used
Authentication auth = SecurityContextHolder.getContext().getAuthentication();
List<GrantedAuthority> authorities = new ArrayList<GrantedAuthority>(auth.getAuthorities());
authorities.add(new SimpleGrantedAuthority("ROLE_USER"));
Authentication newAuth = new UsernamePasswordAuthenticationToken(auth.getPrincipal(), auth.getCredentials(), authorities);
SecurityContextHolder.getContext().setAuthentication(newAuth);
to update the roles for the user once I verified that they had a valid TOTP.