I need to execute a particular transaction with the consent of 3 peers from different departments inside a particular organization how would I do about it with Hyperledger-fabric
Quoting the documentation for configuring an MSP (membership service provider):
Defining one MSP to represent each division. This would involve
specifying for each division, a set of certificates for root CAs,
intermediate CAs, and admin Certs, such that there is no overlapping
certification path across MSPs. This would mean that, for example, a
different intermediate CA per subdivision is employed. Here the
disadvantage is the management of more than one MSPs instead of one,
but this circumvents the issue present in the previous approach. One
could also define one MSP for each division by leveraging an OU
extension of the MSP configuration.
After you have configured your MSP accordingly, then you would craft an endorsement policy for the channel that stipulated that transactions needed to be endorsed by the three departments:
For example:
AND('Org1.member', 'Org2.member', 'Org3.member')
where Org1, Org2 and Org3 are the identifiers for the departments.
Related
I've been using project-id as a prefix in my GCS bucket-names to easily get a unique name.
When I read GCS-best practises
It says clearly not to use project-names or project-numbers (nothing about projectId:s)
But on the other hand, when I spin up GAE, two buckets containing the project-id are automatically created.
Is Google not following their own best practices or did I miss something?
Are the greatest risk of having projectId in bucket name that I give clues to a potential attacker about the project since bucket-names are publicly visible?
It does appear, to some degree, that Google might not be following its best practices (as listed on that page, assuming that project names and numbers mean GCP names and numbers). The default bucket for Firebase projects layered on top of GCP does the same.
The documentation you linked states the reason to avoid using project names:
... because anyone can probe for the existence of a bucket ...
The idea is that if someone knows the name of your project, they could use that to build the full name of the bucket, and use that knowledge in an attack in order to gain its contents. However, if your security configuration is exactly what it should be, then knowing the name of the bucket won't be a problem. This is particularly true for Firebase projects, which use security rules to determine who should be able to access what objects.
I'd take the advice in the documentation as a measure of security through obscurity in order to prevent attackers from guessing the names of your buckets and any of its contents. But if that's not your concern, then ignore it.
It looks like they're just worried about leaking PII. I'm not sure why they mentioned project names, unless it's because someone might include PII in their project name.
Don't use user IDs, email addresses, project names, project numbers, or any personally identifiable information (PII) in bucket names because anyone can probe for the existence of a bucket. Similarly, be very careful with putting PII in your object names, because object names appear in URLs for the object.
The two buckets I see created in my account have an appspot.com suffix. You cannot create arbitrary appspot.com buckets because they have a . in the name and thus are subject to verification:
Bucket names must contain only lowercase letters, numbers, dashes (-), underscores (_), and dots (.). Spaces are not allowed. Names containing dots require verification.
You are right though that the automatic bucket creation is inconsistent with their best practice guidelines.
I'm developing a huge application in django and I need a permission system and I assume that the native user/group permission within django is not sufficient. Here my needs:
The application will be available through multiple departments. In each department there will be nearly the same actions. But maybe an user will be allowed to add a new team member in department A and in department B he is only allowed to view the team list and in the other departments he has no access at all.
I though using a RBAC system would be most appropriate. Roles must also be inheritable, stored in a model an managable through an interface. Any good ideas or suggestions? Regards
What you are looking for is called abac aka Attribute-Based Access Control. It's an evolution of RBAC as an access control model. In RBAC, you define access control in terms of roles, groups, and potentially permissions. You then have to write code within your application to make sense of the roles and groups. This is called identity-centric access control.
In ABAC, there are 2 new elements:
attributes which are a generalization of groups and roles. Attributes are a key-value pair that can describe anyone and anything. For instance, department, member, and action are all attributes.
policies tie attributes together to determine whether access should be granted or denied. Policies are a human-friendly way of expressing authorization. Rather than write custom code in your app, you write a policy that can be centrally managed and reused across apps, databases and APIs.
There are a couple of ABAC languages such as xacml and alfa. Using ALFA, I could write the following policy:
A user will be allowed to add a new team member in department A
In department B he is only allowed to view the team list
In the other departments he has no access at all.
Roles must also be inheritable, stored in a model an managable through an interface.
policyset appAccess{
apply firstApplicable
policy members{
target clause object = "member"
apply firstApplicable
/**
* A user can add a member to a department if they are a manager and if they are assigned to that department.
*/
rule addMember{
target clause role == "manager" and action == "add"
permit
condition user.department == target.department
}
}
}
One of the key benefits of ABAC is that you can develop as many policies as you like, audit them, share them, and not have to touch your application code at all because you end up externalizing authorization.
There are several engines / projects that implement ABAC such as:
AuthZForce (a Java library for XACML authorization)
Axiomatics Policy Server (commercial product - disclaimer: I work there)
AT&T XACML
There are two components to this question:
First, role management. Roles can be achieved through group membership, i.e. departmentA_addMember & departmentB_listMembers. These Groups would have corresponding permissions attached, e.g. "Member | Add" and "Member | View". A department in this context may have more resources included, that require separate permissions. Django allows to extend Objects with custom Permissions.
Second, inheritance. Do I understand you want to have individual Groups being member of other groups? Then this is something Django would require you to implement yourself.
However, should you be looking for a really more complex authentication solution, it may be worthwhile to integrate with 3rd party services through, e.g. django-allauth. There are sure more/other solutions, just to throw in one name.
I am adding users to my ca-server's config file. I want to know what are the differences between roles, affiliations and attributes?
In tutorials I can see that roles is assigned to one of these: "client,user,peer,validator,auditor,ca". I want to know can be use some other role? If a user is assigned "client" role then can he have a validating role running with that identity. What's the difference between "client" and "user"? What's the difference between "peer" and "validator"? And also what is auditor specifically.
I think affiliations are used to categorize identities. Is that right?
Identity type can be any arbitrary string as far as Fabric CA is concerned.
I think of affiliations as hierarchical tags. Each identity can be tagged (affiliated) to (with) one affiliation in the hierarchy. When an identity is associated with an affiliation, it is affiliated with that and all the child affiliations.
1) Affiliations are currently used during registration and revocation. You can read more about registration/revocation at https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html
Attributes are key-value pairs that can be associated with an identity. hf.Registrar.Roles, hf.Registrar.DelegateRoles, hf.Revoker, and hf.IntermediateCA are currently in use with in Fabric CA server. These are used to make access control decisions. Currently attributes are not used in any other Fabric components, afaik.
For example, if an identity with “hf.Registrar.Roles” attribute set to “peer,app,user” and affiliated to org1.dept1, can register identities of type peer, app, and user, (but not orderer) that are affiliated with org1.dept1 (but not identities affiliated with org1 or org1.dept2)
I hope this is helps
I am developing an application based on REST services. I've read everything about developing REST web service but one thing confusing me. As I read, all the module or functionality must have unique and meaningful resource name like
http://localhost:8080/rest/create-organization
and
http://localhost:8080/rest/add-employee
But one of my colleagues suggested me that we should have only one resource as a single landing point for all modules and we must send some code in request header to recognize which functionality we want to execute. For example:
http://localhost:8080/rest/application
And, in request header, we should add CRTORG parameter for creating organization and ADDEMP for adding an employee.
On the basis of this keywords we will call appropriate method and will return response.
Is it the right way? If no why?
That's not how REST applications are supposed to be. See more details below.
REST resources
REST stands for Representational State Transfer and this architecture was defined by Roy Thomas Fielding in the chapter 5 of his dissertation.
The key concept of this architecture is the resource. See the following quote from the Fielding's dissertation:
5.2.1.1 Resources and Resource Identifiers
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time. [...]
REST is protocol independent and, when implemented over the HTTP protocol, the resources can be manipulated with HTTP verbs and the resources are identified by theirs URIs. The same resource can have different representations, such as JSON and XML.
For more details regarding resources and resource representations, see this answer.
What your API could be like
Your API could have the following endpoints and operations:
Create an organization (sending the resource representation in the request payload)
POST /api/organizations
Get all organizations
GET /api/organizations
Get an organization using a certain identifier
GET /api/organizations/{organizationId}
Replace an organization using a certain identifier (sending the resource representation in the request payload)
PUT /api/organizations/{organizationId}
Delete an organization using a certain identifier
DELETE /api/organizations/{organizationId}
Create an employee for an organization (sending the resource representation in the request payload)
POST /api/organizations/{organizationId}/employees
Get all employees for an organization
GET /api/organizations/{organizationId}/employees
Get an employee for an organization
GET /api/organizations/{organizationId}/employees/{employeeId}
Replace an employee of an organization (sending the resource representation in the request payload)
PUT /api/organizations/{organizationId}/employees/{employeeId}
Delete an employee from an organization
DELETE /api/organizations/{organizationId}/employees/{employeeId}
I am using IS WSO2 for authorization with XACML. I am am able to achieve authorization for static resource. But I am not sure with the design when it comes to granularization.
Example : if I have method like getCarDetails(Object User) where I should get only those cars which are assigned to this particular user, then how to deal this with XACMl?
Wso2 provides support for PIP where we can use custom classes which can fetch data from database. But I am not sure if we should either make copy of original database at PDP side or give the original database to PIP to get updated with live data.
Because Cars would be dynamic for the application eg. currently 10 cars assigned to user Alice. suddenly supervisor add 20 more car in his list which will be in application level database. Then how these other 20 cars will be automatically assigned in policy at PDP level until it also have this latest information.
I may making some mistake in understanding. But I am not sure how to deal with this as in whole application we can have lots of this kind of complex scenario where some times we will get data for one user from more than 4 or 5 tables then how to handle that scenario?
Your question is a great and the answer will highlight the key benefits of XACML and externalized authorization as a whole.
In XACML, you define generic, global rules, about what is allowed and what isn't using what I would call high-level attributes e.g. attributes of the vehicle (in your case) or the user (role, department, ...)
For instance a simple rule could be (using the ALFA syntax):
policy viewCars{
target clause actionId=="view" and resourceType=="car"
apply firstApplicable
rule allowSameRegion{
permit
condition user.region==car.region
}
}
Both the user's region and the car's region are maintained inside the application's database. The values are read using a PIP or Policy Information Point (details here).
In your example, you talk about direct assignment, i.e. a user has been directly assigned to a vehicle. In that case, the rule would become:
policy viewCars{
target clause actionId=="view" and resourceType=="car"
apply firstApplicable
rule allowAssignedVehicle{
permit
condition user.employeeId==car.assignedUser
}
}
This means that the assigned user information must be kept somewhere, in the application database, a CSV file, a web service, or another source of information. It means that from a management perspective, an administrator would add / remove vehicles from a user's assigned list (or perhaps the other way around: add / remove assigned users from a vehicle's assigned user list).
The XACML rule itself will not change. If the supervisor adds 20 more cars to the employee's list (maintained in the application-level database), then the PDP will be able to use that information via the PIP and access will be granted or denied accordingly.
The key benefit of XACML is that you could add a second rule that would state a supervisor can see the cars he/she is assigned to (the normal rule) as well as the cars assigned to his/her subordinates (a new proxy-delegate rule).
This diagram, taken from the Axiomatics blog, summarizes the XACML flow:
HTH, let me know if you have further questions. You can download ALFA here and you can watch tutorials here.