We want to restrict the members of the Private Team to create\update\delete channel and to add or remove additional members to the Members
We are creating Private Microsoft Team using POST https://graph.microsoft.com/beta/teams with 'standard' template.
We can able to set the following members settings for the Team.
'memberSettings': { 'allowCreateUpdateChannels': false, 'allowDeleteChannels': false, 'allowCreatePrivateChannels': false, 'allowAddRemoveApps': true, 'allowCreateUpdateRemoveTabs': false, 'allowCreateUpdateRemoveConnectors': false },
But it not restricting the members to 'add Members' and 'Leave the Team' i.e Members can able to add other members and they can able to leave the team.
Is there any settings available through Microsoft Teams Graph API to restrict the member options 'Add Members' and 'Leave the Team' ?
Related
I use Microsoft Graph API to list users in my Azure AD B2C tenant. When I try to get it ordered by surname (lastname) I get this error:
Unsupported sort property 'surname' for 'User'.
What's supported is 'displayName', which may contain person name in the form of [firstName lastName] or [lastName firstName]. I wonder if there's any way to get the list ordered by last name.
The code, just in case:
IGraphServiceUsersCollectionRequest usersRequest = GraphClient.Users.Request()
.Select(u => new {u.Id, u.DisplayName, u.Mail, u.GivenName, u.UserPrincipalName, u.AccountEnabled, u.Surname}).OrderBy("displayName");
Unfortunately, you cannot use orderby parameter with surname in either standard Azure AD or Azure AD B2C tenants as of now.
You may post a feedback regarding this feature at Azure Feedback Portal, which is monitored by the product team for product enhancements.
I am trying to add a new member to a MS Team, but I cannot get it to work.
It adds the new member to the group, but that's where it stops. It does not add the member to the team object.
This is what I am doing:
POST to 'groups/' + groupId + '/members/$ref' with the right data.
There is no error. It updates the group with the new member, but when I check the team, the new member is not there. What am I missing?
Adding user by email alias is still not supported. Requesting you to try passing following JSON which is present in API documentation?
Pass DirectoryObjectId instead of email Id:
{ "#odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{id}" }
i'm new to serverless architecture in general, and i'm studying migrating my current php/mysql rest api to serverless arch.
my main concern is access control.
in certain app, i allow users to access content based on role, and groups they are assigned to "
example
role: user groups: [1,2,3] can only access content with group_id: 1 || 2 || 3
is it possible to do such access control in serverless databases like faunadb ?
It is possible to do such access control with FaunaDB and much more with the ABAC system (https://docs.fauna.com/fauna/current/security/abac.html)
Roles:
In essence you have Roles and these roles provide permissions
CreateRole({
name: "access_todos",
privileges: [{
resource: Collection("todos"),
actions: {
create: true,
update: true,
delete: true,
write: true
}
}]
})
(you might notice that this of course gives access to all groups which is not what you want, we'll get to that)
Roles can be assigned to different things:
Keys: simply make a key with that role and that key can only access the groups collection
Functions: a User Defined Function (like a stored procedure) can assume a role.
Entities in a collection or part of a collection: any entity (e.g. Users, ShareLinks, Accounts) could be assigned a role by adding a 'membership.
Roles Membership (assign roles to a database entity):
You assign a role to database entities by using the membership field.
In this case, all accounts in your database will have these privileges. You can also use a function here to filter out a certain type of account etc..
CreateRole({
name: "access_todos",
membership: [{ resource: Collection("accounts") }],
privileges: [{
resource: Collection("todos"),
actions: {
create: true,
update: true,
delete: true,
write: true
}
}]
})
Assume the identity of that entity, (get a key for that database entity):
Then that leaves us with the question: "how do we assume the identity of a user?".
We use login for that. First you create an account with a password:
Create(
Class("account"),
{
data: { email: "alice#example.com" }
credentials: { password: "secret password" },
}));
The important part is the credentials.password field which is a special field for FaunaDB. It will be encrypted and when a database entity has such a password you can use Login to assume the identity of the entity:
Login(
Index("accounts_by_email"), "alice#example.com"),
{ password: "secret password" })
Login will provide you a token and that token will now have all the rights that this account has. Or in other words all the privileges of the roles for which this database entity of the collection 'accounts' is member (and membership is defined on the role with the membership key)
The power of Role predicates and the 'Identity()' function
Ok but how do we get more fine-grained access?
Roles can have lambda predicates instead of booleans. That means in your case you could store the array of groups on the user (or vice versa) and link the account to the user.
privileges: [
{
resource: Collection("Groups"),
actions: {
read: Query(
Lambda("groupReference",
// Write your logic
)
)
}
}
]
In such a query, the lambda parameter is the reference of the entity you try to access (e.g. a group)
One question remains.. how do we check whether the user linked to an account has access to the groups? Well we use 'Identity()' for that which is an FQL function that returns the reference of the currently logged in database entity.
Note: by default you get read/write access to the entity you are logged into. Hence you do not want to store the group ids on the account since a user could in theory change these. This is why I split account and user in my explanation. We will probably change this in a future FQL version since this appears to be confusing/cumbersome.
A few good resources:
- ABAC docs: https://docs.fauna.com/fauna/current/security/abac.html
- ABAC with GraphQL: https://medium.com/fauna/abac-graphql-6e3273945b1c
- Authentication docs: https://app.fauna.com/tutorials/authentication#creating-users
We are building a complete example as we speak which I expect to appear on our blog in the coming weeks.
The application I'm currently working on is a huge ASP.NET MVC web application which uses traditional Windows Authentication model. We are trying to migrate to Single Sign On model using Identity Server 3 and Open ID Connect.
Coming to my question, is there any way/work around to provide access on a user group basis when using Identity Server? The problem here is that the my user groups could either be role based or Active directory groups. I'm looking for something like InMemoryGroup (similar to InMemoryUser).
Something that mimicks the following for a Group of users that can be role based or not:
new InMemoryUser
{
Username = "harry",
Password = "thisispassword#123",
Subject = "1",
Claims = new Claim[]
{
new Claim(Constants.ClaimTypes.Name, "Harry Potter"),
new Claim(Constants.ClaimTypes.GivenName, "Harry"),
new Claim(Constants.ClaimTypes.FamilyName, "Potter"),
new Claim(Constants.ClaimTypes.Email, "harry.potter#hogwarts.com"),
new Claim(Constants.ClaimTypes.EmailVerified, "true", ClaimValueTypes.Boolean),
new Claim(Constants.ClaimTypes.Role, "Administrator"),
}
}
I'm relatively new to Identity Server and Open ID Connect and not able to find anything online and would really appreciate any leads.
To represent the fact that a user is a member of a group you just add a claim. You could add:
new Claim("Group", "Hogwarts Student")
to your in memory user. The claim indicates that Harry is a member of the "Hogwarts Student" group. There is a couple of things going on here you want to be aware of. The constructor being called is:
new Claim(string claimType, string claimValue)
There Identity Server provides some standard ones in the Constants class but you can make up your own. Also, you can have multiple group claims, so you could have
new Claim("Group", "Hogwarts Student"),
new Claim("Group", "Gryffindor House)
If you wanted to see if Harry was in the "Gryffindor House" group, you'd just search through is list of claims where the claim type is equal to "Group" and the claim value is equal to "Gryffindor House".
Finally, the difference between groups and roles is generally more a matter of application semantics that a physical difference in how they are stored. In general, the set of users that can perform the "Administrator" role for an application is just a group of users. It is the way that an application treats users of a group that makes the group a role.
We're developing an app (using Grails Spring Security (formerly Acegi)) in which we'll have thousands of users that span 10-15 discreet user types. In the current system, each user type equates to a "group", and the specific roles and permissions are tied to the group. The user gets all their "roles" from the group.
For example, we might have two user groups:
CLOWN: roles = ride_clown_car, toot_horn, receive_applause
ACROBAT: roles = do_flip, walk_tightrope, receive_applause
We have three users, one assigned to the CLOWN group, one assigned to the ACROBAT group, and one assigned to both (has union of CLOWN and ACROBAT roles).
If we change permissions, we do so at the group level. For example, if we add a swing_on_trapeze permission to the ACROBAT group, all acrobats will automatically inherit it.
In Grails terms, the permissions on the controllers would still be at the role level. So an action with #Secured (['toot_horn']) would allow users in the CLOWN group but not in the ACROBAT group. #Secured (['receive_applause']) would allow both CLOWNS and ACROBATS.
How would I do this in Spring Security given the two-tiered nature of the model (user, role)? Do I need to implement my own custom authentication to collect roles based via groups?
Thanks!
You should be using the new Spring Security Core plugin since the Acegi plugin isn't being developed and is basically deprecated.
But either way, both plugins just expect that there's something like a getAuthorities() method in your user class that returns role instances. In a scenario like this where the user has many groups, just collect all of the groups' roles:
class User {
...
def getAllRoles() {
Set allRoles = []
groups.each { allRoles.addAll it.roles }
allRoles
}
}
This assumes that you have a many-to-many between User and Group:
static hasMany = [groups: Group]
and Group has a many-to-many with Role:
static hasMany = [roles: Role]
To use this set the 'relationalAuthorities' property to 'allRoles' in SecurityConfig.groovy so it uses that instead of the many-to-many between user and role:
relationalAuthorities='allRoles'
There's no configuration required for the Spring Security core plugin since it depends on an application-defined getAuthorities method already, so just use something like this in your User class:
Set<Role> getAuthorities() {
Set allRoles = []
groups.each { allRoles.addAll it.roles }
allRoles
}