How can I view all subscriptions regardless of the 'app registration' that created it?
On our AAD, we have 2 'App Registration', lets call them regAppA & regAppB. We ran into an issue where we used both apps to create subscription for outlook events. This resulted in multiple events firing for a single change which caused issues down the line when handling them.
The problem is if you call :
GET https://graphUrl/subscriptions (with regAppA secret) you will only get the subscriptions created using that App Registration, and likewise with regAppB's secret
To avoid this situation happening again, I would like to run an automated script/program/whatever, that would get all subscriptions created regardless of the App Registration used to create it and flag issues found in the data.
I could do that using https://developer.microsoft.com/en-us/graph/graph-explorer, but I don't know how-to or if you can use delegated authentication programatically. I need this solution to run with no user intervention.
Any help will be much appreciated.
So, I am pretty new to ADB2C Custom Policies but here is what I have:
I have a Custom Policy with a few Technical Profiles.
I have a Custom Page with a bit of JavaScript.
The technical profile calls a REST API for some additional validation. The validation API returns an error code to ADB2C. But what I would need to do now is to display a link in reaction to a specific error returned by my validation API.
What would be the correct way to get an error code from my Validation API through my Technical Profile to my Custom Page and then react to that error in my own JavaScript? I am pretty sure you should be able to do this but I can't find any official Microsoft Documentation on that particular step.
Depending on the error:
B2C service issue, static error issued to the app as described in the Error codes: Azure Active Directory B2C. Also applies to an unhandled error not originating from B2C service, E.G: REST API does not respond, an error is returned to the app.
REST API returns an error in Validation technical profile - Error is shown to the user within the B2C page.
You can:
1: Get error details from the query parameters appended to your app reply url. EG: https://localhost:44316/#error=server_error&error_description=AADB2C90075%3a+The+claims+exchange+%27REST-API-Endpoint%27+specified+in+step+%274%27+returned+HTTP+error+response+with+Code+%27BadRequest%27+and+Reason+%27Bad+Request%27.%0d%0aCorrelation+ID%3a+5b64bf9c-739b-4d1b-8bb2-d03f3fb7a811%0d%0aTimestamp%3a+2020-05-07+00%3a46%3a42Z%0d%0a
2:
Customize the api.error content definition and do some javascript handling there.
Prefered option (also applicable to 1) is make API always return 200 but with response content including a success (boolan) and error related properties so that you can redirect the user to a custom content screen using preconditions based on the claims output from the aformentioned response properties.
I've built an API-based integration with DocuSign (using their PHP SDK), and am now at the point of deploying to the production server. I have reconfigured everything with the production integration key, public/private key pair, user and account IDs, endpoint URL, etc. replacing the demo ones. The OAuth portion of the conversation is working fine, and I get a valid token back. When I then try to send an envelope, I hit a USER_LACKS_MEMBERSHIP error, and cannot figure out why. As far as I can see, everything about the API user is the same between the demo and production systems.
I've authorized the application and made sure that it's in the list of "Applications with Access to DocuSign".
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Most of the documentation that I can find on this simply repeats the generic error text: "The UserID does not have a valid membership in this Account." If I go to the account admin and look at the list of users, the one I'm expecting is right there, with DS Admin permission; not sure what else might be done to give them "membership". One mentioned not using SendOnBehalfOf, but I'm not, so I can't really remove that.
All the code is identical, just configuration that's changed. Not sure where else to look. Anybody have any suggestions for what to try?
FURTHER INFORMATION
I've tried the getUserInfo call in the SDK, passing the same access token I use for the other call. It returns successfully, showing that it is for the user I'm expecting, in the one group we have, on the production server. And yet, when I enable logging again, as this same user, there is still zero record in the resulting logs of any of this API activity.
Attempts to do things like list templates with the SDK fail with the same USER_LACKS_MEMBERSHIP error.
Using the Diagnostics API (again, through the SDK) to check logging status shows that it is NOT enabled (despite my enabling it in the UI), but can be enabled with a separate call. Subsequently attempting to use listRequestLogs in the SDK generates a 404 error, though the URL matches what's listed in the API documentation (/v2/diagnostics/request_logs). Not sure whether these findings confirm that I'm somehow logging onto the API and the UI with different users (even though the user name and internal ID match), or that there's some problem with the logging facility in DocuSign.
The problem turns out to be the URL I was using for API calls. I switched from demo.docusign.net in testing to www.docusign.net in live, but being in Canada we need to use ca.docusign.net. For those who find this later, you can get the correct base path to use from the oauth/userinfo endpoint, or the getUserInfo() call through the SDK (PHP SDK, at least; don't know what the analogous call would be in others).
There are 3 things to consider:
API calls are made to an endpoint (URL) that contains the account # (either GUID or short form) in the url. Take a note of that number in the url.
Auth Token is a token for a specific user in a specific account.
UserId for the specific call. That is a specific user in the account.
If the user is not in the account, or there's a mismatch between #1 and #2 - you'll get this error. You must work with a single account and have it in all places as well as the user must be a member of this account.
Re:
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Since the request logging is not showing your API activity, the problem is that the person you've logged in as on the web tool is not the same as the person (user id) that you've logged in as on your application.
Solution for OAuth Authorization Code authentication: double check that when your app is logging into DocuSign, you're using the account.docusign.com authentication server, not the account-d.docusign.com auth server. (Look at the URL in your browser during the login sequence.)
Solution for OAuth JWT authentication: re-check that the impersonated user id is from the production system and you're using the right authentication server
I'm trying out the new model for unified app authentication using passport-azurea-ad from this reference https://learn.microsoft.com/en-us/azure/active-directory/active-directory-v2-devquickstarts-node-web
The integration is successful,but every time I do login,I get redirected to a page where I get to choose from my existing microsoft accounts or add a new one.
Why is the session or account not getting picked up automatically, if the user is already logged into his azure or microsoft account?
My requirement is user session should be picked up automatically(not for the first time where he gives consent) if he is logged into his azure account or micrososft account
this page needs to be avoided , if he is already signed in
The reason is a technical limitation. Let me see if I can explain briefly:
When a request comes to the v2 endpoint (login.microsoftonline.com), the v2 endpoint can not detect the presence of an existing consumer account session (login.live.com).
Therefore, the v2 endpoint must make a query (via an iframe hosted on the login.microsoftonline.com page) to login.live.com to detect if a consumer session exists or not.
If a consumer session exists, the v2 endpoint should show the user an 'account selection' screen, like the one you depict in the question.
If a consumer session does not exist, and the user only has one business session, it could auto-login the user with that business account. However, by this time the user has likely already been waiting for a second or so for the query to login.live.com to complete. It might be a strange user experience if the page auto-completed after a second.
The v2 endpoint could definitely show a loading spinner or something to hold the user until the decision can be made, but it was decided that having the user click a tile was an acceptable alternative.
We're building a mobile application that uses Facebook login and attempts to show users their friends that are also using the application.
We generate an access token as part of the login process and pass this up to our server hosted in Azure.
When we request the users friends using:
https://graph.facebook.com/me/friends?access_token=[access_token]&fields=id%2Cname&limit=5
We get the following response on our Azure servers:
{"data":[]}
However requesting the URL directly from my local browser returns a number of records - regardless of whether I'm logged into Facebook or not.
The Facebook App that the user logged in via is published to live (otherwise they wouldn't be able to log in at all).
The only users that return results when called from within Azure are users configured as testers or developers in the Facebook app - is there a setting I've missed?
Looks like the "Country Restricted" setting was causing the problem - we'd limited this to users in the UK which meant requests from the Azure servers in Dublin where returning empty.
Removing this restriction (or possibly increasing to include Ireland) resolved the issue.
Note that this restriction doesn't impact test users, developers or administrators, all of whom work throughout testing and into release.