I have a jhipster microservice named as blog and a jhipster gateway.
I have created a entity named "Farmer".
I have Created below two users in keycloak.
Users:
Pradeep and
Rahul
1) FOR ROLE_ADMIN
2) For ROLE_USER
While Accessing enitity in Admin panel in jhipster gateway, I am getting unauthorized error for admin (Pradeep), whereas for user (rahul) I am able to access entity.
PFB screenshots.
i) Admin Panel Home Page
ii) Admin Entity Page
When admin tries to click on farmer entity below is the error I am getting.
iii) User Home Page
iv) User Entity Page
When user (rahul) tries to access farmer entity he is able to access it.
Please let me know what could be the issue.
Admin users should also have the ROLE_USER role in order to access entity page. This is because the entity routes are secured by default to the ROLE_USER role.
For example, notice the authorities array in the bank-account.route.ts from the sample app:
{
path: '',
component: BankAccountComponent,
data: {
authorities: ['ROLE_USER'],
pageTitle: 'jhipsterSampleApplicationApp.bankAccount.home.title'
},
canActivate: [UserRouteAccessService]
},
Related
We're trying to secure the Solr 8.11 Dashboard. KeyCloak serves as an IDP in this case. All Querys (SELECT, UPDATE, etc.) should be accessible without any Login screen.
The Solr Security.xml looks like this:
{
"authentication":{
"class": "solr.JWTAuthPlugin",
"blockUnknown": false,
"scope": "openid",
"wellKnownUrl": "http://keycloak.fqdn.com:8080/auth/realms/My-Realm/.well-known/openid-configuration",
"clientId": "Solr-auth",
"rolesClaim": "roles"
},
"authorization":{
"class":"solr.ExternalRoleRuleBasedAuthorizationPlugin",
"permissions":[{"name":"core-admin-read",
"role":"profile"}]
}
}
This works so far but does not seem quite right. Notice how I had to specify "profile" as a Role. If I put "solr-admin" as a Role I get the following Error Message from Solr when logging in:
The principal JWTPrincipalWithUserRoles{username='******************************', token='*****', claims={exp=1651702368, iat=1651680768, auth_time=1651680768, jti=************************************, iss=http://keycloak.fqdn.com:8080/auth/realms/My-Realm, aud=account, sub=********************************, typ=Bearer, azp=Solr-auth, nonce==************************************,, session_state==************************************,, acr=1, allowed-origins=[http://solr.fqdn.com:9991], realm_access={roles=[MyCustomRole1,MyCustomRole2, MyCustomRole3, solr-admin, MyCustomRole4]}, resource_access={account={roles=[manage-account, manage-account-links, view-profile]}}, scope=openid profile email, email_verified=false, preferred_username=testuser, email=myemail#fqdn.com}, roles=[profile, email]} does not have the right role
My User (testuser) has been assigned to a few different Roles. (Like MyCustomRole1) I've also created the Role "solr-admin" and assigned my User to this role. But somehow the JWT Token has "roles=[profile, email]" in it. So I have to put profile or email into the Solr security.xml. Every KeyCloak User is a Member of both Roles.
Is there a way so that Solr allows a Login if the Security.xml has solr-admin instead of profile as the Role name?
I am developing 2 related websites which are public website and CMS.
Currently I have an api for registration which is POST /users
It takes 3 fields which are username, password and permissions.
There are 3 permissions:
-Superadmin (having all access right)
-Editor
-Member (only having view access right)
Both of these users can login CMS.
In my public website, viewers can registration as Member using above api.
E.g. The parameters will be
{ username: 'ken', password: '12345678', permissions: 'member' }
What if some hackers simply open Postman and send api request with below parameters
{ username: 'hacker', password: '12345678', permissions: 'superadmin' }
In this situation, the hacker can create an account with "superadmin" permission and can access all of my secret Data in CMS.
What is the most secure way to handle this kind of api?
I setup and sucessfully run jhipster with OKta but when I login my account only having ROLE_USER.How can I added ROLE_ADMIN for my account.I add ROLE_USER and ROLE_ADMIN like instruction -
Create a ROLE_ADMIN and ROLE_USER group (Users > Groups > Add Group)
and add users to them. You can use the account you signed up with, or
create a new user (Users > Add Person). Navigate to API >
Authorization Servers, click the Authorization Servers tab and edit
the default one. Click the Claims tab and Add Claim. Name it “groups”
or “roles”, and include it in the ID Token. Set the value type to
“Groups” and set the filter to be a Regex of .*.
I do log in the user very well. It is working fine in symfony2. During registration in the DB the role and a state_id are going to be saved.
role: ROLE_USER
state_id: 4 //e.g. has only permissions to do some extra actions
Is there a way in symfony2 in the security.yml that I give permissions to targets with role and state_id?
Better use different roles for this, not a state id. For example: ROLE_USER, ROLE_USER_4, etc.
I'm trying to understand something about Symfony and the "super admin".
When I use FOSUser to create a user with super admin privileges
php app/console fos:user:create adminuser --super-admin
I'd firstly like to know what means (from the doc)
[...]Specifying the --super-admin option will flag the user as a super admin[...]
I imagine it means granting ROLE_SUPER_ADMIN to the user because I don't see any super-admin field in the user table.
Secondly, while (still from the doc)
A super admin has access to any part of your application
security:
role_hierarchy:
ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH, ...]
Why do we still need to configure the access hierarchy for it ?
Looking at FOSUserBundle's code you will find that the CreateUserCommand if invoked with the --super-admin flag will call the UserManipulator with a boolean argument $superadmin=true.
Now the UserManipulator calls the UserManager who will create a User Object, call it's setSuperAdmin() method and persist the new user afterwards.
The method looks as follows:
public function setSuperAdmin($boolean)
{
if (true === $boolean) {
$this->addRole(static::ROLE_SUPER_ADMIN);
} else {
$this->removeRole(static::ROLE_SUPER_ADMIN);
}
return $this;
}
So answering your first question:
Yes, the --super-admin flag causes FOSUserBundle to create a new user with the ROLE_SUPER_ADMIN role.
You still have to include the role hierarchy in your security configuration because the ROLE_SUPER_ADMIN role basically doesn't differ from any other role.
It's just a convention provided by the Symfony standard edition that users with role ROLE_SUPER_ADMIN should not have any access restrictions.
If you want the ROLE_SUPER_ADMIN to bypass all security voters by default - have a look at JMSSecurityExtraBundle's IddqdVoter which implements this for the special role ROLE_IDDQD. But this has already been suggested in your other question here.
By defining the hierarchy, you explicitly grant it the ROLE_ADMIN and ROLE_ALLOWED_TO_SWITCH roles (or other custom roles you could have)
If you comment this line, and you try to access with your ROLE_SUPER_ADMIN user to an action with a ROLE_ADMIN check, you will get a not allowed error.
The ROLE_SUPER_ADMIN is just a convention for the name the super administrator role should have, but it does not have privileges by it's own, you have to explicitly grant them to it.