Properties null when using /users but not when using /me/contacts - microsoft-graph-api

When getting contacts from https://graph.microsoft.com/v1.0/me/contacts I get all properties for a user, ex:
{
displayName: 'Joe Joeson',
jobTitle: 'Administrator',
department: 'HK',
mobilePhone: '09823987234',
businessPhones: '8934598743',
mail: 'joe#mail.com',
}
But when I get all users of the organization (with https://graph.microsoft.com/v1.0/users?$select=displayName,jobTitle,department,mobilePhone,businessPhones,mail,userType) the same contact doesnt get some properties, ex:
{
displayName: 'Joe Joeson',
jobTitle: null,
department: null,
mobilePhone: null,
businessPhones: null,
mail: 'joe#mail.com',
}
Why? Its the same contact? Or am I missing something? Should I get all contacts from the organization in another way?
I have confirmed that all properties are set in https://portal.azure.com

The /contacts and /users endpoints return two different entities. A contact entity represents an Outlook Contact from the current user's Exchange mailbox whereas the a user entity represents an User directory object from the tenant's Active Directory instance.
The reason you're seeing two different results is because you're returning two different entities. The first is the Joe Joeson contact from your Outlook/Exchange mailbox and the second is the Joe Joeson user from Active Directory.
The reason you're seeing less information from /users is due to your requesting the Read all users' basic profiles (aka User.ReadBasic.All) scope. This scope can only see a limited number of properties from a user resource: displayName, givenName, surname, photo, and mail.

Related

does serverless databases like faunadb support role based auth?

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.

userType field - which values are allowed?

Microsoft Graph API's User entity has field "userType". According to documentation there is no any information about this. There is one line: "A string value that can be used to classify user types in your directory, such as “Member” and “Guest”. Supports $filter.". So there is no any limitations :-)
Can be "userType" null? I can't PATCH existing user manually via graph api - graph api return an error. But on production we have some users, which have "userType": null
Which values are valid for "userType"? Can you provide it in documentation or here please?
According to your questions, I suppose you want to know the valid value of the field userType. we can refer to the content of User Entity.
For your first question, we can set the field userType to null, not " " or "null". When we create a user, the default value of this field will be Member if we didn't set it.
We can patch existing user. Based on my test, we can modify it like this:
PATCH https://graph.microsoft.com/v1.0/users/{userid}
{
"displayName": "XXX",
"givenName": "XXXX",
"jobTitle": "Marketing Director",
"userType": "Guest"
}
This will modify the user'userType from Member to Guest.
For your second question, according to the content of User Entity and the article of Azure AD User, the valid value for userType is "Member" and "Guest". Based on my test, it is sure that only these two values can be used.

"Value cannot be null.\r\nParameter name: source" with https://graph.microsoft.com/v1.0/users/?$select=id,mySite

I tried MS Graph API with following GET request: https://graph.microsoft.com/v1.0/users/?$select=id,mySite
However, it reports error Value cannot be null.\r\nParameter name: source.
It works if I remove mySite or change it with another user property such as userPrincipalName.
This is a known limitation of the users endpoint (i.e. the collection of users). From the documentation:
Note: Listing users returns a default set of properties only
(businessPhones, displayName, givenName, id, jobTitle, mail,
mobilePhone, officeLocation, preferredLanguage, surname,
userPrincipalName). Use $select to get the other properties and
relationships for the user object. However, only the following
properties can be selected for individual users, and not for collections of users: aboutMe, birthday, hireDate, interests, mySite, pastProjects, preferredName, responsibilities, schools, skills, mailboxSettings
For easier reading, the list of unsupported properties are:
aboutMe
birthday
hireDate
interests
mySite
pastProjects
preferredName
responsibilities
schools
skills
mailboxSettings

Apache Usergrid 2.x: can you restrict API access by a Data Entity's property value?

Say I have the following API, where users can have zero or more registeredIds, which model identifiers by type (with effective dates).
Two examples of registeredIds include:
// Social Security Number
{
"id" : "111-11-1111",
"type" : "SSN",
"validFrom": 315554400000,
"validTo" : null,
"registrationAuthority": "United States Social Security Administration"
},
// Employee ID
{
"id" : "12345678",
"type" : "employee-id",
"validFrom": 1262325600000,
"validTo" : null,
"registrationAuthority": "YoYoDyne"
}
When Anonymous User requests an employee, e.g.,
https://api.usergrid.com/your-org/your-app/users/janedoe
Anonymous User should only get a single registeredId.type with the type value "employee-id." Administrators, however, should see both the "employee-id" and "SSN" registeredId.types.
How would Apache Usergrid apply access control by the registeredId.type? I know I can assign permissions, but this is too restrictive. Can I create some kind of Entity SubType? Or should I handle this through relationships?
Currently, Usergrid does not allow you to set property validation checks. One solution to this problem is to have separate "EmployeeID" entities, have a connection from each User to that their id entity and setup permissions so that only authenticated users can access the EmployeeID entities.

Grails: String(username) as primary key, but save and get id string(username) with ignorecase?

I am using a string "username" as the primary-key of a table,
But when saving and getting the column with the username id I want the case to be ignored so that new users can't try to impersonate another user.
e.g. When registering a new user
username = Daxon
username = DaXoN //this should not be allowed
When getting the unique username it can be typed in any case and still be obtained.
Youtube do this with their usernames.
e.g.
youtube.com/user/Daxon
youtube.com/user/DaXoN //Should go to the same profile of 'Daxon' anyway
Domain Class
This uses username as the primary key
class User {
String username
String password
static constraints = {
}
static mapping = {
id generator: 'assigned', name: "username", type: 'string'
}
}
I then scaffold the controllers and views,
so can anyone help me on saving and getting unique usernames with case ignored?
One way you can prevent the second user from registering a name that differs only in case is to create a case insensitive unique index on username at the database layer. If you try to save a name that case-insensitively matches an existing one, you'll get a database exception. This is the default with mysql, but for other databases, something like the following should do it:
create unique index username_csunique_idx on user(lower(username));
I'm not aware of any way to specify that kind of index in the domain class DSL.
To find the objects, query by username case insensitively. For example, User.findByUsernameIlike(userName), or User.find("from User as u where lower(u.username) = ?", [userName.toLowerCase()]) if you prefer HQL.
You can modify your save and get methods of the generated controler to do string comparrisons. Before inserting a username you could do an HQL query that does a case insensitive comparrison on the user name you want to insert to make sure that no user name already exists. See the "HQL And Case Sensitivity" section of the following link. http://dev.wavemaker.com/wiki/bin/view/Dev/HqlTutorial#HCaseInsensitiveQuery

Resources