The document https://learn.microsoft.com/en-us/outlook/add-ins/inside-the-identity-token, it introduces the content in the outlook AddIn id token, and i found there are two different keys "ISS" and "APPCTXSender", i want to know what's the different usage between them. Also I want to know which part of them i can used to identity one domain/org/tenant.
To uniquely identify a user via identity token, we recommend that you combine the msexchuid and amurl properties in the response (see "Generating a unique ID"
on this page.) As for the other half of your question, could you tell us more about your scenario and why you are looking for tenant/domain?
Related
Specifically, can SCIM be used to add Users to pre-existing (non SCIM-created) groups? We need to provision users via SCIM, but then add them to Groups created manually in the site (a .Net application).
As I understand it, it can't be done like this. Group Update requests (i.e. PATCH requests) seem to require the "id" attribute as the unique identifier for the group, and this "id" seems to be only generated in SCIM Create Requests. So if a Resource (Group / User) wasn't originally created via SCIM, SCIM can't update/replace/delete it. Is that correct?
e.g. PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
I thought about a workaround convention, such as using "user:1234" and "group:1234" as the "id" attribute format (i.e. [resource type]:[internal type-specific ID]), and then any User or Group can be specified by "id", even if it wasn't created via SCIM. But that seems pretty hacky.
Is there a better way of doing this? Many thanks for any help, very new to SCIM!
Yes, SCIM can be used to manage "brownfield" scenarios where existing non-SCIM created objects exist.
Typically the logic flow that happens for a user object is:
GET on /users with a filter (as defined in RFC7644 3.4.2.2) using an attribute that is uniqueness constrained (such as userName, email).
If no user found matching that criteria, create a new user with POST to /users
If a user was found, it should bereturned with an id value even if it was not created via SCIM
The general logic of "Search using a friendly identifier -> create if not found/cache the id value and associated it with existing user in the other directory" is pretty simple and can be successfully used with other object types (ie: groups) as well.
I am currently building an Alexa application that analyzes a user's name. I currently have a slot (called name) that uses the built in AMAZON.US_FIRST_NAME slot type. I want to validate the name by comparing it against amazon's list of US_FIRST_NAMES, instead of having to download a list of names somewhere and comparing the user's name against the list. Is there any way to do this through the Amazon Developer Console?
Note: In Amazon's docs (https://developer.amazon.com/docs/custom-skills/validate-slot-values.html) I have read that there are ways to validate built in slots. However, on the development console, the validation tab for my name slot only allows me to accept or reject the user's input from a list of names that I have provided, not Amazon's built US_FIRST_NAME list. Have I missed something?
In the Alexa console, you have three options:
You can define a custom list of values to accept or reject, or you can choose to accept only the slot type's values and synonyms.
If you see the option to accept the slot type's values and synonyms, I imagine this will do what you are looking for.
If for some reason it doesn't give you that option, then you could actually create a custom slot type and copy and paste the entire list of US names from Amazon into the proper place in your JSON file, though this would make for quite a large file.
I hope this helps.
JSON API REST endpoint with permissions-restricted fields
I am working on a JSON API-compliant REST api. Some endpoints contain fields that should be restricted (read-only or not available) for certain users.
What is the best way to architect the api to allow that certain users have access to certain fields, while others do not? By "best", I mean:
Most compliant with REST standards, ideally JSON API standards
Most clarity in terms of preventing bugs and confusion on behalf of clients consuming the API
I am considering the following options, each with their set of concerns/ questions. I would be more than grateful for any other solutions!
Option 1: Return null on restricted fields for users without permissions
Different data values would be returned per-user. Is this strictly anti-REST?
Lack of distinction between null meaning "null value" and null meaning "You don't have access to this"
In REST/ JSON API architecture, is it okay for an endpoint to return different data per user, based on permissions? I have the impression that this would be contrary to the spirit of resource-based REST architecture, but I could not find anything specific to point to in any doc or standard (e.g. JSON API). Also applies to Option 2.
Is there any paradigm for adding some sort of "You don't have access" flag in the resource's metadata?
Option 2: Exclude restricted fields entirely for users without permissions
Different data values would be returned per-user. Is this strictly anti-REST?
Possibility of "undefined" errors in client, when trying to retrieve field value
Option 3: Move restricted field(s) onto another endpoint, available as an ?include='field_name' relation for those with permission
Example: /api/entity includes attribute field "cost" which is only available to Admin users. Admin users can request cost data via GET /api/entity?include=cost. For all users, "cost" is exposed as a relation in the resource object, with a "type" and "id".
This is the option I am leaning toward. The main con here is endpoint clutter. I have a lot of relations that would need to be made into separate endpoints, simply to support a permissions-quarantined data on an already-existing endpoint.
In the JSON API specs, I am having trouble determining if it's ok for an endpoint to exist as a relation only, e.g. can we have /api/entity/1/cost, but NOT have a top-level api endpoint, /api/cost. My assumption is that if a resource has a "type" (in this case, the relation type being 'cost'), it also has to live on a top-level endpoint.
In this scenario, the client could get a 401: Unauthorized error response if a non-admin user tries to GET /api/entity?include=cost or GET /api/cost/:id
Note: I have already built a separate permissions schema so that the client can determine which CRUD privileges the user has, per top-level endpoint, before making any requests. Permission sets are indexed by resource type.
Any help on the matter would be very much appreciated! And if anything needs to be clarified, feel free to ask.
I would definitely not use undefined or null to indicate fields that the user is not allowed to see. To me, that feels like a lie and represents that the data is really not there. They would have to really know your API in order to get a grasp of what is really going on.
I would recommend something more like your 3rd option, except I would make it a different endpoint altogether. So in your example, the endpoints would be:
/api/entity/1/cost
and for admins
/api/admin/entity/1/cost
or something like that.
This way your server code for the admin endpoint could just be focused on authenticating this admin user and getting them back all the fields that they have visibility on. If a non admin user tries to hit that route, reject them with an unauthorized status code.
I'm not saying that you should not implement the GET param to be able to specify fields as well. You can if you want to, but I don't think it just won't be necessary in this case.
For example, I have a field that give user to type their domain, the user can type any domain on this, but I don't valid this domain is belong that user. Of course, I can generate a random number text file for user to upload, and when I get the random number text file, if it is match, I can just treat it as a valid domain holder. But, except from this method, is that anyway to do so? Thanks.
Options I have seen:
Have user Create a Text file in document root, check for it
Send Email to contacts listed in whois (Or other ROLE type accounts (postmaster, hostmaster, etc...), with token they need to
return
Have them create an 'A' record in their DNS that is unique and you can query for.
There really isn't any other way of telling if they have control over the domain. Using whois information isn't 100% accurate as people don't update it, or their info isn't registered to them, or is hidden behind something like domains by proxy. There is no standard information in DNS, that can tell you ownership. Since google uses the DNS method and the text file method (I think), you can probably safely assume that is a good way to verify it.
When working with the Blogger API the user ID is expected to be numeric. I found out my numeric ID by looking at the URL for my Blogger profile page. However, I want my users to be able to use their usual Blogger user name. So:
Is there a way to convert Blogger
user names to numeric user IDs?
Is there a way to pass in user names
instead of IDs to the Blogger API?
Thanks!
It depends on what you are trying to do, but in most use cases you don't need to explicitly know this information because the authToken will take care of resolving these issues for you if you use the default URLs with the API. But, in the interest of providing an answer in case you really do need to know this:
After the user authenticates, just request some information, like the list of blogs, and you'll be able to extract the ID number from your choice of several places in the response.
Not really, except that during login you use the username. Otherwise you need to use either default, assuming an active authToken, or the ID to reference a particular user's Blogger content.