I'm using Azure AD for an OAuth Client Credentials flow, including hitting this endpoint to get a token:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
I have a requirement to measure the performance of this call (as in how long it took to return a response) - are such timings made available in Azure?
I've looked in the various AAD logs - Audit logs, all the logs which you can send to Log Analytics (AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, etc.), 'Usage & insights'.
When I look in the general Metrics blade and 'Select a scope', searching for a Resource type of 'Azure AD Metrics' doesn't return anything to select.
Is it possible to find such details, and if so where do I look?
The usage of client credential flow will not be recorded in the logs, if you want to measure the performance of this call like how long it took to return a response, you could send a request in the postman, it will give the information.
Related
I have created custom policies with SSO and account migration (you can view them on GitHub here, Note: I removed/edited values for security reasons). I want users to be able to sign in with a social provider OR local account for the first time. I will then migrate their account from the legacy identity provider to AAD B2C. The following goes wrong at the moment though.
The biggest problem is when the account is migrated and the user can sign in, then when trying to link social accounts, I get the following error.
AADB2C90051: No suitable claims providers were found.
Correlation ID: 4491cd4a-2f98-4a86-8d65-da3f7f26e890
Timestamp: 2022-11-20 10:38:05Z
The weird thing is, if I first sign-in using Google or Facebook (which then migrates the account) then sign-in with Microsoft or the local account, it will work. But when first signing in with either Microsoft or a local account, I get the error.
I've seen this and other posts but cannot find what I am missing. I know the policies are very big, so to start, look in CUSTOM_USERJOURNEY.xml for ProvisionOrSignInNewSocialAccount on GitHub.
By default, the hasPassword property doesn't exist by for existing local B2C user profiles. It is introduced by the linking Custom Policy. You will need to manually (or by script) add value true for that property, and it will start working.
You can use Graph API to add value, so basically PATCH to user endpoint:
PATCH /v1.0/users/12bda93c-f782-431c-b962-52c5304c0668 HTTP/1.1
Host: graph.microsoft.com
Content-Type: application/json
Authorization: Bearer eyJ0...
{
"extension_67a963aa6ce74511923b85511f0f8dad_hasPassword" : true
}
See here for full discussion: https://bytemeta.vip/repo/azure-ad-b2c/samples/issues/430
Slightly related to this question, but scenario is different: AAD-FindLocalAccountWithSocialEmail produces No suitable claims providers were found
In hybrid setup if client credentials grant type is used to get token and if that token is used to get on-prem user messages (https://graph.microsoft.com/v1.0/users('onpremuser#onpremdomain.com')/messages/) using graph api it fails by providing UnknownError.
When debugged on IIS logs error shown was "This token profile 'V1S2SAppOnly' is not applicable for the current protocol." error_category="invalid_token".
However if authorization code grant or resource owner password credential (ROPC) grant if used to obtain token , we were able to get messages of on prem user using graph API.
Have attached screenshot of token for both. How to make client credentials grant work for on-prem user messages access using graph API (in hybrid setup) ?
Update
Update i went and edited web.config of rest in Exchange server to have V1S2SAppOnly in profiles. After that previous error is gone and new error is seen.
Bearer+client_id="00000002-0000-0ff1-ce00-000000000000",+trusted_issuers="00000001-0000-0000-c000-000000000000#ea6064aa-d6fc-48d3-abb8-1728e1f39e0b",+token_types="app_asserted_user_v1+service_asserted_app_v1",+error="invalid_token" 2000008;reason="The+token+should+have+valid+permissions+or+linked+account+associated+with+partner+application+'00000003-0000-0000-c000-000000000000'.";error_category="invalid_grant"
I think the problem is with the aud claim, i.e. the audience for token.
For the first token that you have shared
aud value is 00000002-0000-0000-c000-000000000000. This is the resource Id for Azure AD Graph API and not Microsoft Graph API. For Microsoft Graph API, you should be using https://graph.microsoft.com or Id 00000003-0000-0000-c000-000000000000
this token is probably the one where you used client credentials grant, as there isn't any user claim
For the second token that you have shared
aud value is https://graph.microsoft.com which is correct
this token is acquired in context of a user name anoop so I guess this is the one which is working for you.
What you want is:
Application with Client credentials => Graph API => Local Exchange.
This scenario isn't supported out-of-the-box, but you can however tell your local exchange server to accept those tokens. See this answer https://stackoverflow.com/a/56131954/639153
In a nutshell, you need to change the authentication config of your front-end exchange servers to accept client credentials from the graph api. By default only delegated credentials are supported, and these settings are not documented on the exchange side.
Warning, we tested these settings, and it's working but not supported by Microsoft
This is the blog where I've found the answer to your question. https://blog.thenetw.org/2019/05/13/using-client_credentials-with-microsoft-graph-in-hybrid-exchange-setup/
We have an app that allows a user to connect to Salesforce and import data using OAUTH. Works fine for Dev edition users, but Enterprise edition users sometimes get a 401 Forbidden when the app makes a call to describe after they're successfully logged in.
I did manage to find this nugget in Saleforce's documentation for describeSObjects() that says:
Your client application must be logged in with sufficient access
rights to retrieve metadata about your organization’s data.
Does anybody know what exactly those sufficient access rights are? For Enterprise edition users, does the Salesforce admin need to grant specific permissions to the user, so that user can retrieve metadata?
Any help is much appreciated.
Needed to have full access permissions set on the Connected App.
The salesforce admin controls which users have access to which sobjects via the CRUD settings on the users profile.
Typically you'll want to call describeGlobal first, which'll give you info about which the sobjects the user has access to.
You shouldn't see a 401 from the SOAP API, as SOAP 1.1 requires errors to be returned with a 500 status code. So i'm guessing you're using the REST API, but 401 is Unauthorized, not Forbidden, if you're really getting a 401, it sounds like you might be using an expired access token. The response body should have more info on why you got an error response.
I would like to query simpledb directly from the client using javascript. My application is read-heavy and I rather not route the request through my application server. Is it possible to perform a select request without authentication?
I could set up an authentication server, but this is rather inelegant as it will just be saying yes to every read request and would introduce another bottleneck/speedbump/point of failure.
Do the other cloud db solutions (microsoft, google) have this functionality?
This is possible using AWS IAM (Identity and Access Management) and a server side "token vending machine". AWS docs have an article specifically written for the use case Authenticating Users of AWS Mobile Applications with a Token Vending Machine and sample code for server, iOS, and Android in GitHub. The general technique can be used for non-mobile and/or for JavaScript clients.
Note: a server component is still required to vend out the temporary access tokens. However, the volume of these requests can be significantly reduced (up to once every 36 hours). The remaining requests are from untrusted client to SimpleDB directly, no intermediary.
General Technique
anonymous client calls your token vending machine (your server)
token vending machine knows the secret key, calls AWS to generate a temporary token
token is created with read-only access policy (example below)
token lasts for a maximum of 36 hours, default 12 hours (api docs)
vending machine returns token to client
client calls simpleDB API using anonymous, temporary token; cannot write to SimpleDB
Read Only Access Policy
From AWS sample code "Read Only Access Policy"
{
"Statement": [
{
"Action": ["sdb:GetAttributes", "sdb:List*", "sdb:Select*"],
"Effect": "Allow",
"Resource": "*"
}
]
}
This extends beyond SimpleDB. You can set an access policy for several other AWS resources (see full access policy example).
Variation to Replace Dynamic Client-Server calls with Static Resource
Although you cannot eliminate a server component, clients don't necessarily have to talk to the vending machine directly:
scheduled job generates token every N seconds where N + fudge == token expiry
job writes token to public S3 bucket (or any other static resource)
set appropriate maxAge cache-control header based on fudge
anonymous client reads token from static URI
client authenticates with token, makes read-only calls to SimpleDB
You would need to sign all requests with your server. I think that's what you mean anyway. You could still save some bandwidth.
I'd say, as soon as a JavaScript client can authenticate itself, everyone could.
An authentication server is required, you can use EC2 for this.
I am writing an application in Google appengine python. Due to the limited support of the appengine environment I have to implement some of the functionality on external dedicated servers. Is there an authentication mechanism available that will preserve login information over the external servers and appengine.
The system you want should probably work something like this:
When a user visits the 'other' server with no session cookie set, the server redirects the user to a special URL on the App Engine app - let's use /authenticate - with a 'next' query string parameter that provides the URL of the next stage (described in #3).
When App Engine receives a request to /authenticate, it checks if the user is signed in there. If they're not, it prompts them to sign in. Then, it generates a token for the user's session, and signs it with an HMAC, using a secret shared by both servers, and redirects the user to the URL provided in step 1, with the HMAC included in the query string.
When the 'other' server receives a request to its special URL (specified in step #1), it validates that the HMAC matches, using the shared secret, and if it does, uses its own session support to set a cookie on the user's browser under its domain, to keep track of the user from then on.
If the 'other' server needs to obtain more information about the user, it can use an API it shares with the App Engine server to request, out-of-band, more information about the user using the token it was given and the shared secret.
This is very similar to the procedure OAuth uses, but entirely noninteractive for the user. It's also the procedure that SSO systems such as Google Accounts use to 'transfer' sessions to other trusted parties.