Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When using LDAP to provide the certificates, users are always set to type "client" #378

Open
sophiebella28 opened this issue Oct 3, 2023 · 0 comments

Comments

@sophiebella28
Copy link

I have recently been trying to configure a connection between the LDAP server that we use for storing user credentials and the fabric-ca server. In our configuration, we are using NodeOUs to determine user permissions - when not using LDAP, and registering with the ca directly, we set this using the -type flag set to one of admin, peer, client or orderer. However, it seems that when using LDAP configuration, the user is always set to a default of type client, which cannot be changed through any LDAP attributes or API calls.

This makes the LDAP configuration with the ca unusable if you want to have any sort of policies set up requiring type admin/peer/orderer, as the certificate always identifies it as type client. Here is a link to a stackoverflow post where they had the same issue, for added context on the issue - https://stackoverflow.com/questions/63834220/set-admin-role-for-an-ldap-user-in-hyperledger-fabric-ca.

I'm pretty sure that this can easily be fixed by just editing the file fabric-ca/lib/server/ldap/client.go, specifically the getType function on line 342 - just adding an attribute lookup in LDAP for an attribute Type or something similar, and then if that value exists return it, otherwise still defaulting to client.

If there is a way to set the type of a user when getting the details from LDAP, please let me know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant