Reference - https://developer.okta.com/docs/reference/api/groups/#group-attributes
In a group object, an id is unique, though the profile is not unique. The profile contains the name and description of a group.
Does this mean that Okta doesn't ensure that groups have unique names?
Correct, you can have more than one group with the same name
Yes, Okta enforces this at least on the UI when trying to create a group with same name.
Note: this might not be true for groups created with sync (and thus the documentation puts it like that). Couldn't run that experiment for lack of resources.
Related
In my application the users are split in 2 macro categories: Customer and Backoffice, every category has a subset of role, for example MANAGER and USER for Customer type and different ones for the Backoffice type.
So a user could be a Customer with a MANAGER role or a Backoffice with, for example, a SALES role.
Every Spring + Cognito guide on web uses cognito:groups to map the Spring ROLE, but for my case I would need to nest groups which is not possible on Cognito.
I've been thinking to use 2 custom attributes ( writable only by the admin) to set the category and role of the user respectively.
My question is, is there any disadvantage to using attributes instead of the groups?
One major concern is, those custom attributes won't be available as claims in the access token. But groups are available. So If you plan to use acces_token you may have to consider that.
There are some other minor considerations that I can think of, which may or may not be related your implementation:
Maximum number of custom attributes per user pool is 50.
Once created, you can not edit the name, min/max length and mutable property of the custom attribute. Also we can not delete that.
Even though nested groups are not supported in Cognito, is it not an option to create groups like: category_role? example: Customer_ MANAGER?
In the Preventing duplicate Items article, it mentions that you can use a specific combination of fields to determine if there are duplicate items or not. And specifically OAuth institutions, it says the combination of fields are: customer's user ID and institution_id. I'm confused what the customer's user ID is. I'm not familiar with this identifier. Can somebody explain?
The customer's user ID would be a value in your own application's business logic, not part of the Plaid API. In most Plaid use cases, alongside an Item, you would typically store some kind of user id that associates it with a specific user in your system. The logic here is saying that if the same end user in your system has multiple Items with the same institution, they are probably duplicate Items.
This question is really made of two parts.
Using Parse, I'd like to have the following [simplified] scheme, where I have Users who are part of secret groups, and there are discussion that can appear across a few groups at one. That is Users who are part of Group A also are added to the GroupA role, and have access to discussions in Group A.
My trouble is, when I create a new discussion and tell it the groups it should appear in, how do I query for the roles and add them to the Discussion as well? I'm really fuzzy on this roles/ACLs business, even after reading extensively.
User(firstname, lastname)
Group(members, secrets)
Discussion (groups, note, comments)
Create a Role when you create a Group. Assign a pointer from the Group to the Role. Set the ACL for the Group to the Role (for write, it can be public read or whatever you want). When you add users to the Group, add them to the Role so they have access through the ACL.
For your Discussion you need to add all of the appropriate Roles from all of the Groups to the ACL list so that all of the users in all of those Roles have access.
I know we can show content based on a users access level using Joomla ACL, but is it possible to show content to all users except for one specific group? If so, how?
I've tried creating an access level called news that includes all groups except no_news group then assigned my module access level of news.
Unfortunately users belonging to the no_news group were able to see the content. Any suggestions?
The no_news class is inherited from registered.
Is your no_news group inherited from Public? If so, exclude Public group from NEWS access level. Basically the idea is that if the parent group has access, then all child groups will also have.
I need to manage some uses in system, so user management is a feature , and add/delete user is a Scenario? I want to know one principle to design them, thanks
Yes, you are correct.
# user-mgmt.feature
Feature: User management
Scenario: User addition
Given that no user named 'doe' exists
When I create an account for 'doe'
Then the list of users will include a record for 'doe'
Scenario: Deletion of non-existing user
Given that no user named 'doe' exists
When I remove the account 'doe'
Then I get an error message
Have also a look at how to create more concise features and the git examples.
My advice is to just create a feature file and run cucumber. It will tell you what to do.