I noticed the operation metadata page shows the "Rest user defined endpoint" even if not explicitly added as DTO attribute, but defined within the AppHost.Configure method.
I wonder if it would be possible to show within the metadata page, among other operation details, if a given operation(DTO) requires authentication (defined at operation or service level) and all the required authorizations(roles and permissions) if any.
This has now been added on the Metadata index page which will display a yellow key for Services which require authentication, e.g:
When you mouse over the key it will also show which permissions or roles the Service needs.
It's also added on the metadata detail page which will list which permissions/roles are required (if any), e.g:
This feature is available from v4.0.43+ which is now available on MyGet.
Related
Question: Using Microsoft Graph how do we display the manager of a user? For example, using Microsoft Graph Explorer you can get a signed-in user profile info by calling https://graph.microsoft.com/v1.0/me. But this call does not return all the fields - specifically not the manager field.
I tried https://graph.microsoft.com/v1.0/me?$select=manager but it still did not return manager.
In the Relationships section of user resource type you see a manager field for a user's manager. And the Json representation of that Relationships shows manager field as follows:
"manager": { "#odata.type": "microsoft.graph.directoryObject" }
But I am not sure how do we use it to get he manager of a user.
UPDATE:
Following is a screenshot of just a portion of result from the query from the user #CarlShao. In fact it is returning tons of attributes for manager object. But I'm showing just current screen of my laptop:
If you need to expand the user's organizational relationship, you should use the $expand parameter, which supports expanding the user's directReports, manager and memberOf relationships.
GET https://graph.microsoft.com/v1.0/me?$expand=manager
referenceļ¼list manager and expand parameter.
Update:
You can specify $select inside $expand to select the individual manager's properties: $expand=manager($levels=max;$select=displayName)
https://graph.microsoft.com/v1.0/me?$expand=manager($levels=max;$select=displayName)&$count=true
Don't forget to add request header: ConsistencyLevel=eventual
I am using Azure API Management to proxy requests from Internet to our backend systems. I have a Product entry on Azure Portal and an API entry associated with the product. Generally access to the API must be by subscription, but I would like the method returning OpenAPI specification (as well as probably few other methods) to be accessible without subscription (freely).
I see "Requires subscription" checkbox on the Product level as well as on API level, but not on a method's level. So I need either:
bypass subscription check for certain methods while keeping access by subscription for others, or:
same but vice versa: keep the access free for API, but enforce subscription check for certain methods (not preferable, as this fraction is greater).
I checked the list of policies and did not find anything applicable for my case. Moreover this link states:
Subscriptions can be associated with various scopes: product, all
APIs, or an individual API.
Is there a way I can workaround this limitation?
I mean that, maybe you wanna some of the methods(less amount) in an Api can be called without a subscription while the left need. And I searched the ms document but failed to find such policy.
The link you provided also intended that. From my point of view,
how about trying to add a separated Api containing those methods that
don't need subscription?
I have a custom policy which adds a custom value, HoldingId, to new users who sign up (using these docs) as the value is passed to the policy via the token (along with verified_email).
I was hoping to not need to create a custom policy for sign in, so used the Azure Portal UI to create the custom attribute against the b2c-extensions-app application (and am using the respective client and object ids to line it up with the custom policy), and using the Portal have added this custom attribute to the sign up/sign in policy claims.
Using the Graph API, I have been able to successfully confirm that the custom value is saving against newly signed up users (returning as extension_[AppId]_HoldingId), and these new users are able to sign in subsequently without issue using the built in sign in/sign up policy.
However, any users which already existed in the directory are no longer able to sign in. Unfortunately, because it's a built-in policy, I'm not sure of a way to dig into the logs a-la App Insights to see what's going on.
My suspicion is that because these existing users don't have this custom attribute against them, the built-in sign up/sign in policy is attempting to get this value and failing.
Is it possible to get the built-in policies to ignore this attribute on users who don't have this attribute set, or will I need to create a custom policy to handle this scenario with a default value?
For context, the HoldingId is not required for existing users (application needs to be backwards compatible). This is also my first venture into B2C, so I'm still learning many of these concepts.
I've implemented IPersistedGrantStore, and defined a Client that has properties RequireConsent and AllowRememberConsent set to true. I've also removed offline access scope from that client as I've read somewhere that Consent is always forced if offline access scope is requested, as per OAuth specification.
When I go to the login screen for the first time, I'm presented with consent view, click allow and remember my decision, I can see the record in DB table PersistedGrants being added with type user_consent. Next time I try to login, that record is fetched from database by my implementation of IPersistedGrantStore, but the consent view is still presented. If I then click allow again, DB throws an exception because IS4 is trying to insert another PersistedGrant record with the same key.
Did I overlook certain setting that would make it behave as expected?
PS. I've implemented all major stores and everything is kept in SQL Server db, not using any of those InMemory stores.
After substantial amount of debugging, here's what the problem was:
_ScopeListItem.cshtml from 6_AspNetIdentity sample, has this section of code
#if (Model.Required)
{
input type="hidden" name="ScopesConsented" value="#Model.Name" />
}
This is evidently rendered only if the scope is marked as required. Those scopes that are marked as Required are only ones that get posted to controller action.
In my case I had a Client requesting OpenId and Profile as standard scopes, and also three scopes defined by my ApiResource. Admittedly I didn't mark the Api scopes as required, but the problem was also that the Profile scope wasn't required by default.
So when saving the Consent, the Data property didn't contain Profile scope, and there was a mismatch of requested and consented scopes on all following login attempts, which triggered the Consent process.
I'm developing an app using Parse.com for BaaS. Aside from regular security checks, it's my understanding/philosophy that part of security is to assume someone HAS broken in, and then limit the amount they can access/delete/mess up.
One way I'd like to do this is to have a per-user rate limit on certain API requests. I can imagine a sort of naive method where I keep a list of who has accessed recently and when, and check that list before allowing a request of that type to go through (I'm thinking beforeSave for various custom classes).
Is there a better, ideally built-in way?
Though Parse.com doesn't have options for configuring this, parse claims that they keep track of suspicious activities and attempt for DDoS attacks are monitored. But not sure to what extend this is possible, because this specific problem is scenario wise relevant/irrelevant.
You dont have an option to do user level rate limit, but they will report any suspicious activities found like redundant hits from same device.
As given in the Parse docs here, They support two levels of permissions, Class level (via Data browser) & Object level (using ACLs)
Configuring class-level permissions
Parse lets you specify what operations are allowed per class. This
lets you restrict the ways in which clients can access or modify your
classes. To change these settings, go to the Data Browser, select a
class, open the "More" dropdown, and click the "Set permissions" item.
Class level permissions is a manual way of giving access to specific users or roles on a class.
In your case, you might probably need object level permissions based on Access Control Lists(ACL).
Access Control Lists
The idea behind an ACL is that each object has a list of users and roles along with what permissions that user or
role has. A user needs read permissions (or must belong to a role that
has read permissions) in order to retrieve an object's data, and a
user needs write permissions (or must belong to a role that has write
permissions) in order to update or delete that object
Create a new role and add list of users to that role who can access. Then set an ACL like this on the other objects.
{ "role:YourRoleName":{"read":true, "write" : true}}
You can now dynamically add or remove users in that role without updating individual objects.