I have implemented a data model based on Party Organisation Data model
It works fine with every aspects .Each representation of entity is as a party
and Major party types are
Person
Organisation
In party type Person I can add multiple person types like
Super User
Organisational Administrator
Manager
User
Now I have to add a role based settings for the person .My system consists of Multiple organisations and persons are different in different organisation. Super user can control all person,Organisation.
Persons under Super User depends on the Organisation
Refer my basic data model in the above picture
I need to implement different permission levels in this system.Also it must have an ability to add more person levels and their permissions
One of my solution
Party is available with these major party types
Organization which consists of tenants
Person ( Which consist of Super User, Tenant Admin, Tenant Manager, Tenant Executives etc
and more
Relationship between Party defined in party model is by party_relation and it is specified in party_relation_type ( Party Level Relationship )
For example
Main Organization to Tenant Organization
Tenant Organization to Tenants
How to arrange different Person Levels under different tenants
Person levels are maintained by hierarchy in Person type
Add Common column Hierarchy which consist of ancestor_id,Parent_id,hierarchy_level,hierarchy_path to Person_type
Introduce a person_type_relation ( Person Level Relationship )
For example
Tenant Admin to Tenant Manager
Tenant Manager to Tenant Executive
Introduce a Permission Mechanism table , separate tables for person_relation_type and person_relation_type_permissions.
This describes which permissions for a particular relation
Related
I am in the process of designing a Blazor Server app that sits on top of a single MSSQL db.
I have done a fair amount of research and learning on the subject but I am still very new to Core Identity, so I need to better understand how it is meant to be used so that I can properly design the Authentication and Authorization pieces.
The app will consist of organizations. Users can belong to one or more organizations and within each organization, can belong to one of two roles: Coach or Student. But the Coach in one organization could be a student in another organization, and a student could be a student of more than one organization. But all of this should be tied to a single user account/login. If a user belongs to more than one organization, they will be presented with a screen to select which organization they want to access after completing the login process. Once they have selected the organization, their activity and access will be limited to that organization.
What would be the proper way to handle this type of arrangement? Since one user could be a coach in one org and a student in another, are roles the proper way to handle that? Or would those be claims where for example I would store the ID of the organization as the value of a claim called "Coach" or "Student"? Or some other way?
Initially, I was planning to only use Identity for Authentication and then use my own custom logic to perform Authorization based on these criteria, but I don't want to reinvent the wheel if I don't have to.
Thanks in advance for your guidance and recommendations on this.
So, I am fairly new to Laravel and cannot figure out the best way to establish this relationship. I have created a restaurant management system, and successfully created a login system with certain roles. Users can have the four roles: Admin, Waiter, Cashier and General.
Admin can access most of the system, waiter and cashier certain parts and "General" users only the timesheet module. This works, however I want the admin to be able to view its employees.
The problem is that I want the admin to be able to create Employees without the requirement for a user account on the system, but I also want that every User account is automatically either an Admin (Admin role) or Employee (Waiter, Cashier and General).
So basically every user is either an Employee or Admin, but every Employee does not have to be a User. And then I want to connect my Timesheet Module to the Employee Module, instead of the User module.
If I'm doing this in a very complicated way and you know something better, please let me know. Or otherwise post a solution :-)
Hi roles can apply in two different ways. A role can be an authentication method and it could be a type of employee.
It all depends on what you are planning to do with an employee. I believe that you need to sort that out first. Since Roles mostly are defining access to an App, because they have a relationship to Abillities/Permissions.
Connecting you timesheet to the Employee is a correct step. Since Employees do not always need to logon. But it needs to be plannable.
So the timesheet would be timeable_type with a timeable_id. I would do the following, i would create a EmployeeType::class containing the types: Weighter, Cashier, General. And the timesheet table i would use the following.
employee_id since the timesheet belongs to an employee
and employee_type_id since you want to be able to differentiate the type of employee.
you could even do a morphable relation ship for even more flexibillity
So the User::class had the abilities(permissions) and is an active user in your app.
The Employee::class does not have abilities but is an administrative value in your app. So an employee basically can only logon when it has a User::class
So the employee belongs to the User so the employee has a belongs to relation to the user.
and the user hasOne relation to the employee
I am new to the Keycloak framework and after writing my own solution painfully we are hoping to convert to KeyCloak. It seems to be a promising solution but unfortunately lacking self describing documentation. I have gone through the tutorials and the terminology, however, I can not seem to mold a suitable model for my authorization use case through Keycloak concepts. I posted my question! in Keycloak mailing list without any response so I decided to reach out here.
Please consider this use scenario:
You provide a SaaS solution for Car Dealerships.
Every dealership inherits a set of default roles upon creation e.g. admin, manager, sales, accountant,..)
Dealership could add/remove permissions to the default roles.
Dealership can define their own custom roles.
A dealership has multiple vendors and each vendor has a couple of roles (admin, accountant, vendor)
A dealership has numerous departments and each department may have their own roles for that department.
Basically you have different roles in different contexts.
In my built-in model, I have a table that connects a Role to a Principal (an entity) and the ACLs (or permissions) are assigned to the roles. The Principal could be any of "DealershipA", "DealershipB", "Vendor1" "Department0".
Now my questions is: What is the best practice to implement this scenario in Keycloak.
How would you add/assign a role to an entity?
Would you consider a Dealership, Vendor or a Department a Resource?
Thank you in advance for all your help,
IIUC this scenario could be achieved with different approaches, based on the level of KeyCloak integration you want to do. Let me try to articulate one such way. This could most probably be suboptimal, however you could probably use it as a starting point.
As a start, the Dealership could be considered as a tenant separator, so users in a single Dealership could be gathered to a KeyCloak Realm 1. A Realm groups users together and it sounds like a Dealership is a such separator (if users are indeed allowed to have access to different Dealerships through the same user profile, then this separation cannot be applied).
On to Roles, in one approach each Dealership, Vendor, Department role (admin, sales, acct etc) could be a Realm Role 2. These are Roles available to users in a specific Dealership. However I can't think of a KeyCloak native way to differentiate between Dealership roles vs Vendor roles vs Department roles. These could be differentiated through a naming standard perhaps (ex: vendor-admin)?
In another approach, each entity (Dealership, Vendor, Department) could also be a Group with own attributes and Roles [3]. One advantage could be that the relationship between the entities could be replicated in Group-Subgroup relationship.
sample-group-hierarchy
attributes-of-a-dept-group
This could give you a start on modeling the entities inside KeyCloak.
In authorization, it looks like you will be able to use the Authorization Services available in KeyCloak [4]. I haven't personally used this feature but if you want to rely on KeyCloak as the PAP, PDP and the PEP [5] this looks like the way to go.
For an example, users can be granted or denied access to resources on a specific vendor or department, since user information contains the user's group relationship. This seems like something achievable with a Group based Policy [6].
To give a more direct answer to the questions,
User creation process should make sure proper Role and (or) Group associations are made
Resources seem to be the services offered by each entity type (ex: add_vendor(), view_accounts())
Hope this helps to get a design going. Since most details are not clear at this moment, the design will have to be redone based on future requirements, but at least with a model to validate against you will be able to do it better.
1 - https://www.keycloak.org/docs/6.0/server_admin/#core-concepts-and-terms#realms
2 - https://www.keycloak.org/docs/6.0/server_admin/#realm-roles
[3] - https://www.keycloak.org/docs/6.0/server_admin/#groups
[4] - https://www.keycloak.org/docs/5.0/authorization_services/
[5] - https://www.keycloak.org/docs/5.0/authorization_services/#_overview_architecture
[6] - https://www.keycloak.org/docs/5.0/authorization_services/#_policy_group
Example:
I have two bounded contexts Exams and Courses. The Exams context has a Student entity that has information about the students to take an exam. And the Courses context has a teachers entity that contains information about the teacher teaching a course.
I also have an AuthService (purely CRUD), that is used for Authentication and Authorisation of users. The AuthService has an Accounts entity, which contains information like accounts user's name, address, phone number e.t.c.
Bringing them all together, The Student and the Teacher both have Accounts hence their information is already available.
I have a couple of question about this.
Is it anti-pattern in DDD to store the AccountId in the Student and Teachers Entity? If it isn't anti-pattern at what point is it ok to collect students account information using the AccountId, In repository or in the API controller, or should we use RPC/API calls.
Is it okay to copy the details needed from the Account entity into a Student or Teacher Entity?
I assume the AuthService is in its designated bounded context for authentication and, Accounts is in that same bounded context too.
Here are my answers:
Is it anti-pattern in DDD to store the AccountId in the Student and
Teachers Entity?
You can store AccountId in Student and Teachers entities. This is not an anti-pattern but rather opposite - this is how different aggregates refer to each other, by keeping the Id of the other aggregates.
If it isn't anti-pattern at what point is it ok to
collect students account information using the AccountId, In
repository or in the API controller, or should we use RPC/API calls.
I don't understand which repository you mean exactly, for Account, Student, or Teacher? Each aggregate root has its own repository and that repository is responsible for storing those aggregates only. It does not know or query other aggregates. If you need to query other bounded contexts, do that from the application layer - if the operation that does this is not a domain concern. If it's a domain concern, then do this in the domain layer by representing another bounded context as a domain service (interface). RPC/API is an implementation detail for the inter-bonded context calls and you can use either way to query another bounded context, as long as the implementation details don't leak into the domain layers.
Is it okay to copy the details needed from the Account entity into a Student or Teacher Entity?
That is also okay. You do that to achieve higher availability for the price of eventual consistency. In such a case, the bounded context/entity that holds information from another one acknowledges that the copy of the data can go stale but that is acceptable by the business terms.
Let me know if any questions. I am a long-run DDD practitioner.
I think you are in the wrong way. Something that is related to Authentication should not to be in the domain layer. Student and Teacher are entity, but Account in AuthService is not entity. As far as I see, you would like to add a new Student or Teacher by using some information that come from Account, but for doing that you should pass this information by fetching User Account info and pass them to Student or Teacher class to instantiate a new object.
For your second question, depends on our business, you could have same properties. DDD just emphasize that you should use ubiquitous language for naming entities and methods and it doesn't matter you use same properties.
I am working on a multi-tenant cloud application and considering using E-mail addresses/passwords for general login credentials. However, I may have the same user (same E-mail address) associated with multiple tenants based on the planned sales model for this application. For example, multiple departments in the same company might be separate tenants, or separate companies must be separate tenants. In either case the same user (with same E-mail address) might be a user of these different tenants.
What are possible design strategies for handling such situation?
One approach I am considering is separating creation and update of the user E-mail credentials from the tenants. In this approach a tenant could invite a user (by sending an E-mail) and the user can use the same login credentials for access to all tenants, merely switching between tenants as desired.
What I have typically seen in current web applications is that the user has to have separate E-mail addresses for each tenants, which seems a burden for the user.
Thanks.
Assuming your question is about the technical design (and not the user experience), this is a pretty straight forward solution. Create the users independently from the tenants, and allow for a many to many relationship that represents the "has access to" phrase.
Depending on your chosen backend, there are different manifestations of the design pattern:
RDBMS: Create a user table, tenant table and a user_has_access_to relationship table
Directory Server (LDAP): Place the users into a single OU within the directory, and create the tenants as group objects. The users could then have the memberOf attribute set for each tenant they are able to access.
The LDAP option above has the limitation of overloading the group entity. If you are comfortable enough with LDAP schema definitions, you could just as easily create a tenant object and add a hasAccessToTenant attribute to your user object. Taking this approach would allow you to use groups to represent actual user groups (as the object type was intended to be used).
A more advanced design option would include the creation of a "has access to" relationship between tenants. Adding this, along with the user to tenant relationship, would open up more advanced relationship modeling. For example: a tenant with departments or divisions, allowing users with permission to the top level tenant to automatically "have access to" the divisions.
Using the same credential across namespaces in multi-tenant applications is technically possible. For example, when a user logs in, the application can check across the namespaces and determine which all namespaces he belongs to. There is a possibility, the user may have different levels of authorizations against these namespaces. This is also implementable.
The real problem is the experience the application can offer to such users. They will require a special landing page which will allow them to chose between the namespaces. The chosen namespace should be made quasi-permanent during the session, that is, until the user logs out. ( I am trying to implement this in a new application on GAE/Python27 )
Other possibilities are restricting the user to a single namespace and asking the user to use different credentials against each namespace, which seems to be the prevailing practice.