It seems policies / permissions are directly checked against claims. How can ABP be used in an enterprise application that has hundreds of permissions?
It seems policies / permissions are directly checked against claims.
That is not true. Permissions are indirectly checked against these claims:
AbpClaimTypes.UserId by UserPermissionValueProvider
AbpClaimTypes.Role (role names) by RolePermissionValueProvider
AbpClaimTypes.ClientId by ClientPermissionValueProvider
For each claim, permissions are checked against PermissionGrant in the cache or database.
More about Permission Value Providers:
https://docs.abp.io/en/abp/4.3/Authorization#permission-value-providers
How can ABP be used in an enterprise application that has hundreds of permissions?
In most cases, grant multiple permissions to a role and then grant a role to multiple users.
(You can also grant permissions directly to user, since the permissions are not stored in claims.)
There is ongoing development to not use claims for roles, then hundreds of roles will be no issue:
https://github.com/abpframework/abp/issues/8620
I have a SPA React app with a NetCore API backend. This api is also used by another application.
I want to authenticate and authorize the SPA users using AAD B2C and the second app using the client credential flow. I understand that client credential flow is not supported by B2C. And I read that to achieve that I'd need to register the api again in Active Directory (non-B2C) as well as the client app and configure that using normal AD.
That will leave me with SPA and API registered as apps in B2C and API and client app in normal non-B2C.
IF.... all that is correct, how do I make the API validate both different types of clients? Authorizing users from B2C and client app through client credentials flow against AD non-B2C
For authorizing users from B2C, you just need to refer to this document: Tutorial: Grant access to an ASP.NET web API using Azure Active Directory B2C.
Your main concerns is for client credentials flow against AD non-B2C.
I have a test and the steps are the same as in the normal AD:
I registered a web API application in Azure AD B2C. Add an appRole in its manifest.xml.
"appRoles": [
{
"allowedMemberTypes": [
"Application"
],
"description": "Writers Have the ability to create tasks.",
"displayName": "Writer",
"id": "d1c2ade8-98f8-45fd-aa4a-6d06b947c66f",
"isEnabled": true,
"lang": null,
"origin": "Application",
"value": "Writer"
}
]
Then I registered a web App application in normal AD. Add the API permission to it.
Use client credentials flow to acquire the access token.
I am using the Bosch IoT Suite's Permissions Service.
I have an issue generating agent credentials. What are the steps and parameters i need to specify to generate agent credentials? I am trying to create an agent credentials which is able to auto activate newly created user accounts.
here are some steps to create the agent credentials for Bosch IoT Suite Permissions:
Purpose
Use a AuthorizedClient of Permissions to
activate Users without having them to do it themselves
reduce the permissions of a user by creating agent-credentials with a subset of rights (to reduce the impact if credentials are abused)
Prerequisits
You have booked the IoT Permissions Service on bosch-iot-suite.com
You have created a User in the Permissions Service
Check out the Guide from Bosch IoT Permissions: https://permissions.s-apps.de1.bosch-iot-cloud.com/docs/developer-guide/index.html#Getting-started---Bosch-IoT-Suite_216542264
Guide
Create the Authentication Token with your desired user
POST https://permissions-api.s-apps.de1.bosch-iot-cloud.com/2/rest/authentication
Headers:
x-im-client-access-token: <....>
Authorization Basic <username:password> (Base64 encoded username:password)
Create the Authorization Token with that Authentication Token
(warning) You need to be careful to put the right scope into that Authorization Token (to activate users, use scope "pn")
POST https://permissions-api.s-apps.de1.bosch-iot-cloud.com/2/rest/authorization/HAX?scope=pn
Headers:
x-im-client-access-token: <....>
Authorization: Bearer <authentication token>
Create the Agent Credentials with the Authorization Token
POST https://permissions-api.s-apps.de1.bosch-iot-cloud.com/2/rest/users/current/agent-credentials
Headers:
x-im-client-access-token: <....>
Authorization: Bearer <authorization token>
Body:
{
"scopes": [ "pn" ]
}
Usage in Java implementation
Include Permission library into your application
Follow the guide from Bosch IoT Permissions
Create a Permissions client instance
Permissions.createClientBuilder()
.clientId(clientId)
.clientSecret(clientSecret)
.serviceUrl(serviceUrl)
.build();
Create an authenticated Permissions client (be aware, that the authenticated Permissions client has an expiration date, so you need to recreate it from time to time)
permissionsClient.authenticate()
.agentCredentialsId(agentCredentialsId)
.password(agentPassword)
.andCreateAuthorizedClient()
.executeAndGet()
.getAuthorizedClient();
While I tried IBM MobileFirstPlatform [V6.3], I am not able to login to console. This is the development server comes with the studio.
I didn't configure the administrative security for console.
I didn't add/modify any user.
Error Log as follows
[AUDIT ] CWWKS9104A: Authorization failed for user admin:worklightRealm while invoking WorklightServices on /management-apis/1.0/runtimes/EvidencerMob/applications. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin:worklightRealm while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightServices on /management-apis/1.0/runtimes/EvidencerMob/applications. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightConsole on /index.html. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightConsole on /services. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightConsole on /index.html. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
[AUDIT ] CWWKS9104A: Authorization failed for user admin while invoking WorklightConsole on /services. The user is not granted access to any of the required roles: [worklightadmin, worklightmonitor, worklightoperator, worklightdeployer].
The MobileFirst console, in the MobileFirst Development Server (the developer edition available as an Eclipse plug-in), does not require any login. In case for some reason a login is required, the credentials to use are admin/admin.
It's unclear to me why you got this error, but one possible way around this is to:
Close Eclipse
Open the Eclipse workspace and delete the MobileFirstConfigServer folder
Open Eclipse again, start the server and visit the console
I'm able to protect Worklight console with an user inside worklight.properties file (on Liberty or WAS environment).
How can I protect console with a LDAP user (outside of the worklight.properties file)?
Yes, you can do this.
You will need to edit your authenticationConfig.xml as follows:
Add a LDAP loginModule
Add a LDAP realm
Update the existing "WorklightConsole" custom securityTest to use the new realm
After the above changes, once loading Worklight Console and entering the user credentials,
these should be handled by the loginModule to authenticate against the LDAP server.
See the following IBM Worklight Getting Started training module, which is about this very topic:
Using LDAP Login Module to authenticate users with LDAP server