Does Corda support user credentials for Accounts / Party? Here there is a common username, password for the node access through RPC. Is there a way to validate the user (Node user / Account) in Corda as well?
Application user (Node user / Account) <----> Application <----> RPC Client <----> Cordapp (Node)
the only way to connect an external client to a node is using the Corda RPC Client
the configuration of the user that can connect to the RPC Client (i.e. username, password, permissions) is in the node.conf (explained here)
you can create multiple users in the node.conf. Up to you to assign these users to a node administrator, or to external users, depending on your security policies. You can set different permissions for each of them, and also set which CorDapp flows they can access to.
If your CorDapp does use Accounts (i.e the account library), and you want them to "run flows" (though, consider that accounts in Corda do not run flows, but it's always the node that run flows on their behalf) from an external client (e.g. a Web app), you have the possibility to:
create a RPC user in the node.conf for each account
create only one user for the RPC client and manage the authentication and authorization of the external users at application level, not Corda level (e.g. JWT, external database, AWS Cognito, etc..). Once authorized, the user can access the RPC client from the Web app and
a mix of the 1. and 2.
I would not recommend to delegate the authentication and authorization of external users only at Corda level. I would keep the concept of "accounts" in Corda and "external users" separated.
Related
Currently .Net Core app has APIs with OpenID Connect configured. It gets user token and validates.
Now have a requirement to implement client credential flow for 2 APIs leaving rest with OpenID connect. These two APIs are triggered by another backend system. By providing client id,secret and grant type = client credentials , back end system is able to invoke these two APIs. But problem is it can also invoke other APIs which i don't want.
Looking for a way to achieve this in .Net Core. Please advise
If you implement client credential flow, the access token will include the Application permissions.
If you implement OpenID Connect flow, the access token will include the Delegated permissions.
In order to control which API the client app can access, you need to verify the permission.
You can learn more configuration from how to verify Application permission and verify Delegated permission.
We are using WSO2IS as IAM server , roles and Users are managed in WSO2IS. WSO2EI WILL be integration server , exposing private APIs
What would be the right way to implement role based access control using , like some set of APIs only to be accessed by users with specific groups. How can I implement this most simplest way ? Is there a requirement of WSO2AM here ?
Thanks
EI is not the ideal way to exposing private oauth secured APIs. Even though you can achieve it with EI, that would be an excessive effort when integrating.
Use API Manager to expose the APIs to your crowd. Configure Identity Server as the Key Manager (Token Manager) of the APIM server. APIM server knows how to talk to the Identity Server to generate and validate access tokens. So there's no explicit effort to integrate the resource server(APIM Gateway) with the authorization server(IAM).
Share the user store between both the servers. (IS and APIM)
Configure IS as the Key Manager of the API server.
Register your API in the publisher/developer portal.
When publishing, you can define role based access restrictions to your API resources from the Publisher portal. (Roe : Scope mapping)
Once you define, IS will always check your roles upon providing an access token for you.
As you've already defined a role : scope mapping, scopes you request in your token generation request, will only be accepted if you (requester) has the expected roles. Therefore, the scope of your token will only be as good as the roles you've got assigned to yourself. Now, as the API resources you've published require a defined set of scopes, not all the access tokens will be accepted when trying to access the APIs. Only the ones with the expected scopes.
Configure IS-KM with APIM
Role based scopes
I was wondering, what's your opinion about using indy for enterprise blockchain. Where the members of the system are different applications, which are onboarded on the platform by a master application. These applications are then given a role of trust anchors, they can then issue credentials to their users. The users can then use the credentials to when they want to use the the rest apis exposed by these applications. Effectively removing the need for the user to login, they sort of just send the zkp in the header.
Is anybody working on a project like this? does an agent like this exist which enables an application ( Basically a webserver with certain routes to be onboarded ?
You seem to be wanting to use Indy as an authentication service for the users of the application. This is a common use case of Indy, but there are simpler approaches than the formulation you describe.
The most common approach is for an organization to run an issuing service anchored to the Sovrin Network. This service issues a credential to users for each application to which they should have access. Each application would implement credential verification. The first time a user tries to use a system, they will establish a peer connection with that system and present their credential over that connection. From that point on, they are immediately authorized by refreshing that peer connection.
This approach saves the organization maintaining their own internal Indy blockchain.
Other approaches include DID Auth, and integration with OpenID Connect.
When we store the Service principal certificate/appKey in the VM (to access the keyvault), we could limit access to that file to just the user account running the program. Other users or accounts wouldn't have access to the secrets in keyvault.
When we use Azure Managed Service Identity to access keyvault from an IaaS VM, my understanding is that any user logged into the VM or any program running on the machine can access the keyvault secrets - is this true?
And if it is, doesn't that decrease the security in case one of the user accounts is compromised?
According to the article access Azure Key Vault, it seems this is true. If MSI is enabled, just need to invoke web request in the VM without e.g. appKey.
And if it is, doesn't that decrease the security in case one of the user accounts is compromised?
It should be, but the prerequisites of the access to the secret in the keyvault is the VM service principal was added as a role in Access control (IAM) and Access policies.
If you want to increase the security, you may need to remove the VM service principal in the Access policies, then it will not be able to access the secret, if you want to the service principal does not have the access to the keyvault at all, remove its role in Access control (IAM).
For more details, you could refer to: Secure your key vault.
Update:
From the doc #Arturo mentioned, it is the fact.
Any code running on that VM, is able to call the managed identities for Azure resources endpoint and request tokens.
AD FS supports OpenID Connect protocol for authenticating users. AD FS supports access policies for WebAPI applications, but not for server applications, at least not that I could find.
Is it possible to define access policy for a server application? The business scenario is really simple: only allow users from a defined group to authenticate given a specific client id.
If an enterprise deploys AD FS with AD DS and deploys several applications (each one registered separately, thus getting a unique client id and client secret), this could be used to allow/disallow users from authenticating to the ADFS for a given (registered) client (relying party).
It appears that this is possible by defining two applications in the same application group:
The server application, which has a client secret in addition to client id
The WebAPI application, for which you can define an access policy.
In order to make this work, you need to assign the relying party identifier (the client id of the server application) to the WebAPI identifiers and ensure that the "Client permissions" of the WebAPI application contain the server application.
If the access policy is not evaluated successfully, the relying party (the application requesting authentication) will receive an access_denied message.
Application group:
Server application:
WebAPI application: