On our existing AAD, we are trying to integrate with FIDO2 authentication.
As part of this integration b/w AAD & FIDO, in azure portal under "Security
Authentication methods | Authentication method policy (Preview)" AD Admin have been provided UI options to enable FIDO Authentication either for a particular user or group which will be followed by end user side set up process using MS self service portal "https://myprofile.microsoft.com"
Are the above steps involved in AAD & FIDO integration, can be accomplished programmatically via graph api endpoints or any other rest end points?
Is AAD having its own API public endpoints apart from Graph API endpoints?If not why AAD not having its own API public endpoints?
The above steps for AAD and FIDO integration can be done via portal at this point . The underlying functions involved are not exposed through any API at this point . the feature is still in preview and is a work in progress. This may change a little more before it goes GA depending upon existing feedback by the users/customers and internal tests.
There is older API called Azure AD graph API but its not being actively developed for any new features. The Microsoft Graph API is the newer API and it is being designed as a single consolidated API (single endpoint https://graph.microsoft.com) with a robust back-end to interact with Microsoft 365 cloud Services. Earlier Micrsooft had many different APIs to manage end user experiences and Identities however as we evolved a lot of customers/partners demanded consolidation so that it was easier for them to write their customer code for management and build any software on top of Microsoft Azure AD hence one single API backend was built and released as Microsoft Graph .
As for the programmatic access to FIDO settings , I would suggest you to upvote an existing feature request related to the same on Azure feedback site. The Azure Feedback uservoice site is periodically reviewed by the product group and it helps in prioritization of requested features for development.
Related
My company wants our IT department to review and approve every tool we connect to Marketo. This is a lengthy and costly approach which I do not seem to fully understand, why. For example, I would like to use the Marketo integration with LinkedIn, Contact Forms 7 (WordPress plugin), or Zoom. There are already existing integrations with Marketo which can easily set up via the API Code provided by Marketo. However, my company wants to review all these as all API integrations have to be reviewed by IT. Does this make sense from a security or functionality perspective? Are the existing Linkedin, Zoom, WordPress integrations proper API connections? What is the difference between an API and integration in Marketo?
Thank you for your help.
I think with the API integration, that would use your own daily API limit whereas the native (existing) connection in Marketo where you can connect to Linkedin or Zoom integration is via Marketo background API which does not count towards your limit. In terms of security review, you might want to discuss to get the details off your Account Manager perhaps.
I'm writing an app development guide and I'm struggling with a few things:
First of all there are currently 2 endpoints in AAD (v1 and v2), there are also 2 pathways of registering apps in the AAD portal (app registrations and app registrations preview). I can't seem to find confirmation that usage of the app registrations preview blade enforces usage of the v2 endpoint, can anyone confirm? Our users authenticate using WS-Federation which is currently not supported by the v2 endpoint which is why I want to avoid usage of v2 for now.
I'm also looking for the best method of allowing access to the Graph API through a service account with delegated permissions (for more granular scoping).
Anyone that can clarify?
Thanks
I can't seem to find confirmation that usage of the app registrations preview blade enforces usage of the v2 endpoint, can anyone confirm?
An app registered in either registration experience can be used with both the v1 and v2 endpoints. Some features can only be configured in the preview experience, though (e.g. support for Microsoft Accounts).
Trying to setup a bunch of logic apps with supporting Azure functions etc. concept is to utilize ML/Azure functions/Logic apps etc. to setup an automated mailing system.
Everything is deployed using ADO/Git with CD/CI pipelines, but we have a problem with the Office365 connector that needs authorisation after creation. For now, we have followed this article that creates a windows form for authentication.
This works fine, but we want to do this at scale and thus are looking for a silent approach, any ideas or links would be appreciated?
PS. Use does not require MFA
At the moment, the Office365 API authorisation works with the OAuth 2.0 Authorisation Code Grant Type, which means, you can only get the authorisation code by getting the user owning the mailbox (or having access to the shared mailbox) to sign in to get the code. This behaviour of the API is by design. Thus, there is no way to fully automate this.
If you don't need different accounts for different Logic Apps, you can create those API connections with PowerShell (still requiring the user to login in) for each environment and then use the already provisioned API in our CD pipeline.
Wanting to know features does the Microsoft Graph API share with the legacy Azure CREST API. I believe the Microsoft Graph API vision is to have this support, as it is aimed to be a unified API for all Microsoft content. On that note as well, what other alternatives are there to the CREST API for partners?
For some context on what CREST provides, see this quote from Partner Center REST API reference.
The Partner Center REST API helps Cloud Solution Provider partners
integrate their existing CRM or billing software with the Microsoft
systems that manage customer accounts, place orders, manage
subscriptions, and handle support requests.
At present, the Microsoft Graph doesn't support Partner Center REST API. You can refer the figure below about the detail support for Microsoft Graph:
If you want the Microsoft Graph to integrate the Partner Center REST API, you can submit the feedback from here.
I'm trying to interact with the Salesforce REST API for an organisation, and was wondering if it had any notion of Service Accounts or Application Owned Accounts. I can't find any mention of it in the documentation, but maybe they use different nomenclature.
I'd like to enable some form of domainwide delegation of authority, so users aren't faced with the pop up requesting access to their data. This is an internal app, only for this particular organisation.
No, there are not service accounts. There are 'Chatter' user licenses that are free but have reduced functionality: http://www.salesforce.com/chatter/getstarted/?d=70130000000tRG7&internal=true#admin
FAQ: http://www.salesforce.com/chatter/faq/