I need background to be run with 2 different roles.
I'm not allowed to do this:
Background:
Given I login as existing user with role "<role>"
And I choose to create new Account
Examples:
| role |
| Standard User |
| Site Admin |
What is the best way to resolve this issue?
You have two separate pieces of behaviour here so do a scenario, or even a feature for each one.
In most applications different rules will apply for users and admins, and in many systems and even different ui's will be used.
A top rule for scenario writing is that its much better to have lots of simple scenarios than a few complex ones.
It's not possible with Background.. you can use Scenario Outline in feature:
For example:
Scenario Outline:
Given I login as existing user with role "<role>"
And I choose to create new Account
Examples:
| role |
| Standard User |
| Site Admin |
Related
Does exists any test management tool that can be integrated with Jira and supports cucumber scenario outline multiple example tables?
I try to use this cucumber feature with xray cloud but it looks that xray does not support this yet. Is there any similar tool that could be integrated with Jira and supports multiple example tables like in below example?
Example cucumber code:
Feature: Log in to the application
As user I want to be able to successfully log in to the application
#XrayTicketId-5000
Scenario Outline: Log in to the application
Given Log in page is opened
When User with <User Role> logs in
Then User should be logged in
And Overview page should be opened
#smoke
Examples:
| User Role |
| Administrator |
| Customer |
| Supplier |
#critical
Examples:
| User Role |
| Technical Support |
| Analyst |
I am creating an application that uses Azure AD user groups to grant permissions to specific resources. For example, a particular set of documents can only be accessed by users in specific groups. The application receives the group ids as claims on the JWT and ensures that only documents assigned to groups in the claims are visible.
Now, the question is how to manage groups correctly in Azure AD. When users are assigned to a group become a member of that group and any groups that group is nested in. This seems to imply that my group nesting should be the reverse of the tree structure I would like. Something like this:
Admin --> member of --> Group with most access --> member of --> group with less access --> member of --> group with least access.
To me this seems backwards but it provides the correct access rights to users added to each group.
Am I way off base here or is this a reasonable way to manage access rights with AD groups?
#JoyWang already covered some good points in answer above. Here are some additional considerations. Disclaimer: Due to nature of question, my answer here is mostly opinion and learning from some cases. Idea is to share how I have seen groups getting used along with some related info.
Are the groups specific to your application or more general purpose? Group membership and nested groups are usually used to organize users & groups logically/intuitively rather than design permissions for specific application
Many times Azure AD Groups are used by more than one application and may have a lifetime longer than any one specific application you're developing.
The way you are thinking about nesting groups based on which one has more access v/s less access you're probably concerned about only one particular application that you're developing and thinking about a group's access to this application. This approach will work out if the groups you plan to create are also very application specific and will NOT be used for any other purpose.
Example1: Your application is a blogging app and groups you create in Azure AD are Viewer, Contributor and Admin. (Admin > Contributor > Viewer)
Example2: You have an enterprise using Azure AD and groups organize users logically, say deparatment wise Marketing, Human Resources, Engineering etc.
So, the way you describe nested groups based on lower access permissions to higher, it will technically work out for a simpler scenario like in Example1 but not for Example2 where groups are more general purpose.
Many times general purpose groups already exist and you're expected to reuse them rather than create new ones for your application which require new assignments/membership all over again, but this may or may not be applicable in your specific case.
Also, there can be multiple people managing these groups and their membership so any design/organization pattern you come up with should give importance to intuitiveness even if you have to sacrifice minor application specific efficiency sometimes.
In my opinion, you can look at both flat or nested groups.. if it makes sense from an organization of users and groups standpoint, not just access permissions. Another fictious example: Marketing Group can have a member group like Marketing Content Approvers because it's a subset of Marketing people.
Do consider Application Roles.
They are specific to an application, tied to it's manifest and can be available to you as part of claims in token.
There can be situations like individual resource based access where you want to give permissions to a specific resource where Application Roles may or may not make sense and you still need to rely on groups or users directly. In any case, it's another helpful option available to you.
Managing Groups (as you've asked about this in comments)
Take a look at Self Service Group Management Scenarios (Delegated v/s Self-service) and also Dynamic Groups for dynamic membership rules based on attributes (requires Premium license though).
In AAD, the permissions of a member in the groups depend on the biggest permission of the group which he is a member of. For example, group A can access a resource and group B can't access it, the man is both in group A and B, then he will be able to access the resource.
To me this seems backwards but it provides the correct access rights to users added to each group.
Let we call the three groups as A,B,C, the permission of them is A > B >C. Obviously, if you add A to B, the permissions of A and B both have not been affected. But if you add B to A, the members in A or B will both have the biggest permission, it is no what you want. The same with B and C. This is why it provides the correct access rights to users added to each group as you said.
So in my personal opinion, seems no need to use nested groups, just use three groups with different permissions, it's enough.
Can you add a user to multiple groups in one login?
No. A user can only belong to one group max. In the UI you can only select one and via API you can only specify one group_id.
Yes. You can add a user to multiple groups at a time provided your application separates your Authorization logic.
For eg, If you have 3 groups i.e., Customer, Manager and Administrator then the customer must have a different login interface where only customers can login, the manager must have a different login interface where only managers can login and so on. This can be achieved but it consists of lot of code related tweaks to be done.
But the recommended approach is that to assign a user to one specific group and manage the permissions at group level.
I'm triying to develop an application which will contain different kinds of companies, and each company will have different roles.
This way, when a superadmin create a company, will define which roles can be attached to this kind of company.
For example, the superadmin could create a shopping center which could have a shop assistant and a director (each of them with different permissions); and another kind of companny which could be a coffee shop, which could have a waiter and a chef.
Then, when an user loggin inside the application, and will want to create a new user, will only have the possibility of select the roles of his kind of company.
But I can't see the way to develop, using the security.yml file and the FOSUserBUndle.
Thanks in advance!
For this kind of purpose, I think you need to implement your security logic inside controllers ; with security.yml you can restrict some entire areas, but I don't think it will help in your case. Maybe you can first define some routes that would be accessible only to some roles (for example, "/waiter/*" for waiters)
Then you can implement like a new kind of roles ; each company can have a field "possible_roles" that will be an array of roles. For example, if a superadmin creates a coffee shop, then you will have possible_roles = { "ROLE_WAITER", "ROLE_CHEF" }
After that you just have to check if the user's role is in the company role's array, and if he has access to the page.
Is it clear ?
I have created a dashboard named ABC Dashboard and a security role named ABC admin.
What I want is that ABC Dashboard is only visible to users who have security role ABC admin. How can I do that?
In short. You can't.
Slightly longer answer.
There are two types of dashboards, system and personal. System can be seen by everyone.
Personal are only seen by the user who has created them - but they can then be shared with other users and teams. Not an ideal solution but does what you want.
This feature is available in CRM 2013 and future versions.