OPC-UA can restrict access to nodes via the userRole mechanism specified in OPC-UA Part 3, ch. 4.8.3:
When a Client attempts to access a Node, the Server goes through the list of Roles granted to the Session and logically ORs the Permissions for the Role on the Node.
A session should map user identity (or the certificate of the client application) to a role. Thus, the server can grant or deny access to nodes.
standard mapping rules can be used to determine which Roles a Session has access to and, consequently, the Permissions that are granted to the Session.
Now, the configuration schema of the server applications allows defining a UserRoleDirectory where I would expect files that somehow link a user (or client application certificate) to a role.
Unfortunately, the UserRoleDirectory appears to be undocumented.
So, the questions are:
Will the OPC Foundation's .NET sample server indeed use files in UserRoleDirectory for said purpose ?
If so, what format take the files in said directory ?
If not so, how to tie users or client instances to roles ?
Related
I've read many tutorials on setting up a realm in Keycloak but it's nowhere mentioned that Keycloak is creating a client called <your-realm-name>-realm in master realm with set of roles:
Why is it needed?
Is the custom realm a form of a client for a Keycloak itself so it needs to create a kind of "virtual" client to handle that relation?
This automatically created client has a set of roles which look to me like a Keycloak internal roles:
Where can I find them in a documentation?
Is the custom realm a form of a client for a Keycloak itself so it
needs to create a kind of "virtual" client to handle that relation?
Kind of; from the Keycloak Documentation itself:
The master realm is a special realm that allows admins to manage more
than one realm on the system. You can also define fine-grained access
to users in different realms to manage the server.
The master realm in Keycloak is a special realm and treated differently than other realms. Users in the Keycloak master realm can be granted permission to manage zero or more realms that are deployed on the Keycloak server. When a realm is created, Keycloak automatically creates various roles that grant fine-grain permissions to access that new realm.
Admin users within the master realm can be granted management privileges to one or more other realms in the system. Each realm in Keycloak is represented by a client in the master realm. The name of the client is [realm name]-realm. These clients each have client-level roles defined which define varying level of access to manage an individual realm.
It is just an implementation detail; Notwithstanding, it makes it easier to conceptually think of the master realm as the top of the pyramid followed by its clients, in which are included the other realms as well. Furthermore, it also allows you to managed the realms from the point of view of the master realm, for instance:
Adding permissions in the form of roles to the other realms. Other approaches would likely be good as well, but the Keycloak developers opted for this one.
We are currently in the process of migrating our user authentication to Keycloak, using an OIDC server. The issue is that the architecture of some of our client applications rely on existing user tables, linked to numerous other tables throughout the services.
How can we go about keeping Keycloak users in sync with the client user, so that if a customer deletes or creates a user on Keycloak, it's reflected in that client DB? Is this generally done through overwriting OIDC methods?
Similarly, when a user logs in through Keycloak, we will require a lookup on the client DB to get additional attributes for the access token, such as the client userId and accountId for that user. Can this be done via overwriting thetransformAccessToken method and making a request to the client BE?
Is there the possibility to limit the access to Service Fabric Explorer to certain services or specific users?
We have a scenario where we host multiple services on the same cluster. The log information of the Explorer shall be only visible for the 'owner' of each service.
No.
You can use access control to limit access to certain cluster
operations for different groups of users. This helps make the cluster
more secure. Two access control types are supported for clients that
connect to a cluster: Administrator role and User role.
Users who are assigned the Administrator role have full access to
management capabilities, including read and write capabilities. Users
who are assigned the User role, by default, have only read access to
management capabilities (for example, query capabilities). They also
can resolve applications and services.
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security#role-based-access-control-rbac
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-roles
You can assign different roles to groups, but you cannot scope a role to a service, so basically its all or nothing, you cannot give granular control
I followed the steps mentioned in the below WSO2 documentation to use WSO2 IS as an Identity Server with WSO2 APIM.
I use WSO2 IS 5.3.0 and WSO2 APIM 2.1.0.
https://docs.wso2.com/display/AM210/Configuring+WSO2+Identity+Server+as+a+Key+Manager
I am able to access the carbon admin console in both the WSO2 IS and WSO2 APIM (in two ports)
https://localhost:9443/carbon/admin/login.jsp
https://localhost:9444/carbon/admin/login.jsp
When I use WSO2 IS console (9443) to change the user roles, most of the times it is getting reflected immediately, using the same access token. How can it be possible ? An access token is provided by WSO2 with some pre configured scopes. Within the same login session, even before the access token expires, If we change the roles of the logged in user, the roles changes are applied immediately and my access rights are changed ? Is it a valid ?
Assume a user "USER1" got an access token with privileged rights and he/she is able to access privileged APIs. Suddenly if the roles are changed and user "USER1" is assigned a normal user rights, and the user is not able to access the privileged APIs within the same login session. Is this how OAuth works ?
Please help me understand.
If I change the roles in WSO2 APIM (9444), the roles are not getting reflected immediately. Some times, it wait for the access token to expire and the gets a new access token. Sometimes, role changes are getting applied even before the access token expire.
What is the synchronization interval between WSO2 IS and WSO2 APIM, to sync the roles?
I couldn't find these roles in mysql db or ldap. Where are they stored in the backend ?
There are differences in IS as a key manager and the inbuilt key manager of API Manager. The key manager comes with API Manager is not a full fledged Identity solution. Hence its role to scope mapping, access control, etc. are somewhat limited in the point of view of Identity Management aspects.
Identity server acting as a key manager provides the full access control mechanism, hence the change in the role should affect fast as possible, even for issues keys. This is one of the reasons of using IS as a key manager.
Question 1
Ans:
Lets say a user has an admin right when he got the access token. The enterprise may decide the user has no longer needs this right and changes that on their LDAP. It should be reflected on key validation as fast as possible. Otherwise the user has continued access to the service as privileged user until key expires, which is undesirable. So the behavior is valid.
Question 2
Ans: Yes, API Manager is strong on managing APIs. However, it is not a use/role management system. Hence there will be considerable delay in reflecting the role change. So, make sure you use IS to manage the user/roles, etc. when your API Manager is configured with IS.
Where is your configured roles
It should be in WSO2UM_DB configured (UM_ROLE table), if JDBC user store is your primary UserStore.
We are considering to use the keycloak as our SSO framework.
According to the keycloak documentation for multi-tenancy support the application server should hold all the keycloak.json authentication files, the way to acquire those files is from the keycloak admin, is there a way to get them dynamically via API ? or at least to get the realm public key ? we would like to avoid to manually add this file for each realm to the application server (to avoid downtime, etc).
Another multi-tenancy related question - according to the documentation the same clients should be created for each realm, so if I have 100 realms and 10 clients, I should define the same 10 clients 100 times ? is there an alternative ?
One of our flows is backend micro-service that should be authenticated against an application (defined as keycloak client), we would like to avoid keeping user/psw on the server for security reasons, is there a way that an admin can acquire a token and place it manually on the server file system for that micro service ? is there a option to generate this token in the keycloak UI ?
Thanks in advance.
All Keycloak functionality is available via the admin REST API, so you can automate this. The realm's public key is available via http://localhost:8080/auth/realms/{realm}/
A realm for each tenant will give a tenant-specific login page. Therefore this is the way to go - 10 clients registered 100 times. See more in the chapter Client Registration of the Keycloak documentation. If you don't need specific themes, you can opt to put everything in one realm, but you will lose a lot of flexibility on that path.
If your backend micro service should appear like one (technical) user, you can issue an offline token that doesn't expire. This is the online documentation for offline tokens. Currently there is no admin functionality to retrieve an offline token for a user by an admin. You'll need to build this yourself. An admin can later revoke offline tokens using the given admin API.