I have a React Application that uses Microsoft AD to authenticate users.
As a first step, and according to Microsoft Documentation, we need to register the application with the Microsoft identity platform.
This is inline with Microsoft Identity Platform Documentation, in this diagram we can see that for ALL types of applications (SPA, Web App, etc), we always need to configure an application in AzureAD:
This process is "cumbersome", and i'm trying to remove it by having the application installed automatically.
Several third-parties do this, such as Zapier, SpecFlow, etc.
Basically, they have a process where:
User logs in on Zapier
User is redirected to Azure AD sign-in page
User is authenticated and authorized
AzureAD shows the Consent Page
User consents
Application is installed on user's AzureAD
I've been reading and searching in Microsoft's Documentation, and i cannot find a single document that shows or even mentions this type of flow.
BUT, i know that this is possible, as there are several third parties that are doing exactly this, as Zapier, for example.
Can anyone point me in the right direction, there must exist some Microsoft document that explains how this process is done!
Apologies if this should be a comment, not an answer. I do not have enough SO reputation to write comments.
Zapier is published to the Azure Active Directory application gallery (1c76d9b0-0826-4b19-8706-29572657af1e). You can do this as well:
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/v2-howto-app-gallery-listing
If an application already exists in the gallery, it does not need to be "registered" in the user's tenant, as the registration definition is defined in the gallery.
Once an app is in the gallery, users can use it only if their tenant's administrators allow this, per the settings on this page:
Enterprise applications | User settings
https://entra.microsoft.com/#view/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/~/UserSettings
From the user's end, there are other governance controls that may impact the user's ability to use your app, but I think "register your app in the gallery" is probably what you're asking for.
Related
I'm building a service where each user has a calendar, I want to sync users 365 calendar events into their calendar, the tricky part seems to be, that this should be done repeatable by background job on the server, to keep them in sync.
I feel like I've read a bible of documentation from Microsoft, but still gotten nowhere. I eventually stumbled upon this article https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds which allows a server to query the graph api, on behalf of users. This is exactly what I want.
Having created a Azure account, and Active Directory service, I found that only users within the tenant can use this, which makes it rather useless, requiring to add users manually from azure panel.
AADSTS50020: User account 'm#****.com' from identity provider 'live.com' does not exist in tenant 'Default Directory' and cannot access the application 'c0193dea-5145-430a-9c90-325f1229a1fc' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
So I'm back at square one, how can I achieve what I described?
I'm not looking for a code implementation, merely a description of how to navigate the monstrosity of Microsoft.
Thank you
Update: Accordingly to Marc link. I tried to flick the multi tenant option, and change the endpoint to use common instead of tenant id. Sadly i'm still getting the same error.
You cannot sign-in to AAD with a non-AAD account using the v1 Endpoint. If you want to use a consumer Microsoft Account (#outlook.com, #hotmail.com, #live.com) then you need to use the Converged Auth model provided by the v2 Endpoint.
I have a walkthrough for the v2 Endpoint that you might find helpful: Microsoft v2 Endpoint Primer. It is similar to the v1 Endpoint but you'll need to register via https://apps.dev.microsoft.com rather than the Azure Portal. Also, v2 apps use Scopes instead of Resources and are multi-tenant out of the box.
This is a broad a question for Stack Overflow. That said, you're incorrect about Azure AD. It is absolutely not limited to a single-tenant. You do however need to register it as a multi-tenant application:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
I created a "Web app / API" app in our organization's "xxx.onmicrosoft.com" Azure Active Directory. The app's "Multi-tenanted" property has been set to "Yes".
We configured OpenID Connect (we use https://github.com/mitreid-connect/) to use the following URLs:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
Please note that we used "common" in the URLs and we didn't use "xxx.onmicrosoft.com" because we want people from outside "xxx.onmicrosoft.com" to be able to authenticate and access our app.
With those settings, the people from xxx.onmicrosoft.com can properly authenticate and access the app.
However, when I use my personal live.com account (with username xxx#gmail.com) to access the app, I get AADSTS50020 error. I am able to properly authenticate with my xxx#gmail.com account, but I do not get redirected to the Reply URL. I'm stuck on Microsoft's Web page with the following error msg:
AADSTS50020: User account 'xxx#gmail.com' from identity provider
'live.com' does not exist in tenant 'xxx.onmicrosoft.com' and cannot
access the application '391e7103-ZZZZ-zz87-xxxx-7xxxxxd5xxxx' in that
tenant. The account needs to be added as an external user in the
tenant first. Sign out and sign in again with a different Azure Active
Directory user account.
What configuration do I need to change if I want people from any identity provider to be able to access my app ?
Like it has been stated here, I expected that people from anywhere could access my app without requiring more configuration on my side.
I'm asking this question because I'm in the process of getting certified for AppSource and this currently blocks me from being able to do so.
AppSource only requires work accounts to sign-in. You are using an #gmail account - which is a personal account - and because you are using the Azure Active Directory v1 endpoint in addition to common (https://login.microsoftonline.com/common), it can't accept personal accounts to sign-in directly - only work accounts.
You have three options:
If sign-in personal accounts is not a requirement for your application, then you can continue using the v1 endpoint and use a work account to sign-in/test your application. This will make you ready for AppSource certification.
If you need/ want to allow personal accounts in your application in addition to work accounts, then you can consider using the v2 endpoint (https://login.microsoftonline.com/common/v2.0) for Azure Active Directory. The v2 endpoint allow both personal accounts and work accounts to sign-in with no effort.A note is the v2 endpoint has some limitations: if you can live with these limitations (for example, your application only needs to sign-in users and eventually make queries against Graph API), then in general it should be fine to use, but if you need extra features like protecting your own Web API with scopes, then this feature is not released at this point (as November 2017). Please read this document for an updated list of limitations of the v2 endpoint.
A third (but less recommended option for AppSource) is to keep using the v1 endpoint and make your application to be single tenant - which is to change the endpoint from https://login.microsoftonline.com/common to https://login.microsoftonline.com/{yourtenantid}, and then use B2B invitations API to invite every external users (including work and personal accounts) to be part of your Azure AD tenant/organization. More information about B2B here as well.
The option '3' above have some consequences for management as well for AppSource: by using this option, you are required to have one Azure Active Directory tenant (if you don't have a tenant already, you can get one using these instructions), and the users being invited will be guests accounts of this tenant - this mean that you need to invite every external user to your application/ tenant. A multi-tenant application allows any user from any organization to sign-in to your application with less management on your side. In general for SaaS applications, multi-tenant configuration is recommended.
For AppSource, also the option '3' leads to a less-immersive user experience (Partner led trial), where the end user won't be able to access your application's demo right away - mainly because that they have to wait for the invitation's email and accept it (user has to accept being guest of your tenant) so that they can access your application.
For more information about AppSource requirements and trial options - please see this article.
I am using Office 365 to manage my calendars. I would just like to publish one of my calendars to my blog. Also, I would like to fully control the style of the calendar. I can enter API URLs into the browser and basic authentication to access my own calendars. So, I could do that from the server to build my calendar page using a server side http client. In this case, I don't really need the full power of OAuth2, which is mainly for letting multiple visitors manage their own content on a third-party site.
It would be nice if Microsoft's Office365 libraries would handle this scenario. It could also include a step where I register for a keys similar to the way Google Maps does. Or do they offer this already?
Does anyone know what steps to take so my scenario would work? Also, would I run up against any usage limits for a popular blog?
While the API is supporting Basic at the moment, that will eventually go away. You can definitely make your scenario work using the authorization code grant flow that's in place today, but it sounds like you may be more interested in the client credential flow which we are going to be releasing support for soon. That would allow you as the administrator of your Office 365 organization to authorize an app to access calendars in your organization without requiring user sign-in.
You register for client IDs and client secrets via Azure AD.
Azure AD is included with Office 365, and registering apps doesn't include any additional paid Azure services.
The client IDs and secrets obtained with the Visual Studio tool are permanent, and not just for debugging. Can you point me at the documentation that said otherwise so I can get it corrected? :)
I am writing a MVC 4 web app and want to use the new WIF and ADFS to Authenticate users. I also want to provide a profile page for users to "self serve" changes like phone number or maiden name.
I am looking for resources/tutorials (a good book) to show me how to wire it all up.
Users will be stored in active directory so I'm guessing that I should use the ADMembershipProvider for some of this. I believe there is a profile store attached to ADFS (or I can set one up) and I want to know if its good practice to interact with it directly or is the an API that with let me add claims etc.
Finally, how does all this fit into the new WebSecurity stuff?
You asked for books on the subject of ADFS. You could try the patterns and practices book A Guide to Claims-Based Identity and Access Control.
In terms of the ADMembershipProvider, you don't need it.
ADFS under the hood handles the AD integration, You configure claims rules which determine which attributes ADFS extracts out of AD.
Update
In terms of editing the user in AD, this is an Identity Manager scenario. ADFS is a STS so it doesn't handle this. You need to do this directly e.g. Howto: (Almost) Everything In Active Directory via C#. Be aware that you need an AD login that enables write access to do this. This is a different credential set to the set that allows you to login to ADFS.
ADFS just provides the login screen. Out the box you don't get any self-service functionality. You need to customise the ADFS screen yourself e.g. AD FS 2.0 Sign-In Pages Customization Overview.
We are planning to create two sharepoint web applications using SharePoint 2010 Enterprise Edition.
All Users that have access to web app 1, should also be able to access web app 2.
This authentication shall be powered by server 2003 active directory.
--> do I need to use claims based authentication?
If so --> can I use Windows Based Authentication with NTLM for that?
The only thing I really want is that users navigating from web app 1 to web app 2 (and vice versa) do not have to authenticate twice.
I do NOT want to configure Kerberos if it is not absolutely necessare though...
Can you give me any hints?
Thanks!
EDIT:
ok - I'll try to be more precise:
In our SharePoint 2010 environment, we've got two web applications running
http(s)://humanresources.domain.com
http(s)://sales.domain.com
Both are running on the same IIS and have host headers configured (with wildcard domain certificate for HTTPS).
Both apps provide a link to the other web application (sales -> humanresources and humanresources -> sales)
Now whenever someone logged in to sales navigates to humaresources, I do not want that that person needs to login again. Therefore I thought I would need claims based authentication???...
Please enlight my brain! :D
EDIT 2:
Thank you for your answers!
#Panagiotis Kanavos - yes we have Users accessing the site from outside our environment: 1) Users which have an AD accound and are working on their laptops outside of our building (e.g.: they have been all day at a customer and are working at home for the remaining hours) 2) We plan to have users without an AD Accound --> Forms Based Authentication: (e.g.: customers accessing our TFS 2010 project protals to get an overview of the project). As far as I know, if you want FBA and WIN-Auth you need to configure Claims Based Authentication...
However configuring a Web Application with Claims Based Authentication did not work. I chose "Enable Windows Authentication" together with "Integrated Windows authentication -> NTLM" as we do not have Kerberos configured (and I'd love to leave it like that ;-)).
However the Users could not login to that application sometimes, and five minutes afterwards it worked. Additionally, when I added permissions to an AD user, SharePoint seemed to save the Token instead of the Group-/Account Id:
e.g.: Instead of MyDomain\user1 it saved something like "0|=MyDomain\user1" and for groups it even only saved weird character strings "022-12.3"
Could it be the case, that my 2003 windows AD does not support that?
IF you are using Active Directory and running both sites within your domain you should not be challenged when users go to either site. It just becomes an implementation issue about who has access to what, either via AD Groups or SharePoint groups.
Claims based authentication is a bit of a different animal. You need to have a security token which contains a number of "claims" about the user, for example UserA is a member of HR and UserB is a member of Sales. Based on these claims you can then have your site/application respond correspondingly. Claims based auth is relatively new for SharePoint and Microsoft and is a bit of steeper learning curve. It may make more sense if you have a mixed mode environment, with both AD and Forms Based Users getting access. However with your described heterogeneous environment it doesn't seem like it's needed.
More info on SharePoint 2010 Authentication is available here.
John
The easiest solution is to create an AD group with the users of both sites and add the group as a user to the Members Sharepoint group of each site. This way users will not have to login at all since Sharepoint will detect the identity of the logged-in user automatically.
Why are you asking about login, claims, and why are you using certificates? None of this is necessary in an intranet scenario where the farm and users are in the same domain or if the farm's domain trusts the user's domain. Do you have users accessing the site from outside your domain?