I'm currently exploring the (Academic Licensed) Office365 API via oAuth access_tokens and have succeeded in retrieving a simple OneDrive folder list via the SharePoint API using access tokens, as a proof of concept.
But this seems to work only for users that are in the Azure maintenance domain that's NOT SSO enabled to our on-premise ADFS server.
The domain that is SSO enabled to our own ADFS server succesfully gets logged in on acquiring the oAuth code and I get a genuine access_token while trading in this code. But using this access_token to retrieve a simple folder list for the user results in this error instead of a folderlist.
{"error_description":"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}
Wich I can't check since I'm not in control of the Azure Sharepoint server.
Did anyone succeed in using the Office365 API icw SSO enabled domains/users?
You'll struggle with an ADFS setup. Any code I've written relies on managed accounts only (i.e. those accounts with a UPN ending with onmicrosoft.com). Each synchronised user from on-premise will have a matching onmicrosoft.com secondary identifier which you should use instead.
Related
I'm writing a small tool that accesses data in a SharePoint 2019.
That SharePoint 2019 is configured to use "Windows Claims Based Authentication"; this means that from Windows machines part of the correct domain, users simply open the SharePoint site from Edge and the simply have access, without being prompted for credentials.
QUESTION: how could I authenticate the HTTP request to the SharePoint REST API that my tool does ?
I tried going in "private browsing"; there I was prompted for credentials, but I could not see any authentication header in the HTTP requests, so I don't know exactly how does the process look (so that I can "reproduce" it in my tool...).
I have a working c#/dotnet Windows desktop application that does its work by hitting various web services in my web application. When the desktop application starts up, it prompts the user for username / password and then hits my login web service, which returns a session token.
I have a large-org customer with many users. That customer wants to provide authentication / authorization for my combined desktop / web application directly from their domain controller. They want single signon, so my desktop app doesn't prompt their users for usernames and passwords.
How can my desktop application retrieve a usable authentication / authorization token from Windows (maybe from the user's Security Principal object)? How can my web application validate that token so it can trust the desktop application and send it a session token?
(My web application runs in my environment, not in the customer's domain.)
With pure-web-app customers I do this successfully with SAML2 and Active Directory / Federation Services. The SAML2 dance gets my user's browser to POST a request to the customer's AD/FS server, which then POSTs a signed response back to my web app.
But I can't figure out how to do it cleanly from a desktop application. Any wisdom?
You can check this samples in github (by jelledruyts): Modern claims-based identity scenarios for .NET developers
It has samples of authentication and authorization using Azure Active Directory and/or Windows Server Active Directory Federation Services.
I suggest read this article Digital Identity for .NET Applications. It's a little old but is a good overview/review.
Tokens come in many different formats. For today’s .NET applications,
however, three kinds of tokens are most important. They are the
following:
User name/password token—This very simple token contains only two
claims: the name of some subject and that subject’s password.
Kerberos ticket—More complex than a user name/password token, a
ticket includes a subject’s name, the name of the subject’s Windows
domain, and other information. Kerberos tickets that are issued by
Active Directory also include an extension that contains security
identifiers (SIDs) that identify the subject and the groups to which
this subject belongs.
SAML token—The Security Assertion Markup
Language (SAML) is an XML-based language that is owned by the OASIS
multivendor standards group. Unlike the other token types that are
described here, a SAML token doesn’t have a fixed set of claims
defined for it. Instead, this kind of token can contain any claims
that its creator chooses.
As soon as the claims are available, they can be used by Windows, the
application, or both. The most common uses of claims include the
following:
Authenticating the user(...)
Making an authorization decision(...)
Learning about this user(...)
Kind of Authentication:
Domain Based Authentication (eg Kerberos tickets):
A domain-based application accepts only a single token format with a
fixed set of claims. One common example is a Windows application that
accepts only Kerberos tickets. This kind of application is easy to
create, and it works well inside a single Windows domain. The problem
is that this simplistic approach to digital identity is no longer
sufficient for many applications
Claim Based Authentication (eg. SAML tokens):
Unlike a domain-based application, a claims-based application can
potentially accept multiple token formats with varying sets of claims.
The token formats and claim sets that this application accepts are
determined by the application itself.
Identity Technologies
Active Directory (AD) Domain Services (full-featured directory service, token source for Kerbero tickets, etc)
Active Directory Federation Services (ADFS) (support for claims-based applications, token source for SAML tokens
Windows CardSpace
Active Directory Lightweight Directory Services (subset of AD services)
Identity Life-Cycle Manager (ILM) (synchronization between different identity stores)
Windows Authorization Manager (tools for RBAC - role-based access control)
Active Directory Rights-Management Services (RMS)
Because AD Domain Services implements Kerberos, the default token in a
Windows environment is a Kerberos ticket. To use this default, an
ASP.NET application specifies Windows Integrated Authentication, while
a WCF application uses an appropriate binding, such as NetTcpBinding.
In either case, the following figure illustrates how a Windows
application with clients in the same domain might use a Kerberos
ticket and AD Domain Services
First versions of AD FS only support SAML with web clients.
ADFS 1.0, supports only browser clients—a restriction that’s scheduled
to change in the technology’s next release.
Hope it helps.
I should preface this with the fact that I've never done this, so I can't give you exact code, but I can point you in the right direction.
You should be able to do this with ADFS and Windows Integrated Authorization (WIA). In a "pure web app", the browser sends the credentials of the currently-logged-on user during the authorization step. In your case, your desktop app needs to do everything that the browser would normally do. Either way, the setup on the web service side should be exactly the same.
In C# with HttpClient, this is the important part:
var httpClient = new HttpClient(new HttpClientHandler()
{
UseDefaultCredentials = true
});
Then, whenever your httpClient sends a request that is challenged with a 401 response, it will automatically resend the request with the user's Windows credentials. This is exactly what a web browser would do. So use that when you get the token.
You may have to send a user agent string in the request, since ADFS seems to limit WIA to certain agents.
Once you have a token, then use the token in your requests to the web service.
The key is that you're replicating what a browser would do. So if you have trouble setting up what the HTTP requests should look like, then access a GET request in your API from a browser and use the browser's dev tools to inspect exactly what the traffic looks like, and use that information to replicate the same request in your code.
Be warned possibly noob question ahead.
I'm a little unsure where exactly Azure AD or IdentityServer is supposed to fit in in the overall communication flow.
Here is a scenario that I often face.
Some "dumb" client (e.g. a Windows App that can't use external assemblies or some JavaScript in a web app) has to contact my Web API which will then contact other APIs or other resources.
If I want to try and implement either Azure AD or IdentityServer as a means of authentication and authorization in the Web API, I don't see that this can be done in any other way, than it has to be the Web API that communicates with Azure AD or IdentityServer as the client doesn't have the ability to do so due to the lack of required assemblies.
If this assumption is not correct, then how would I do this?
If it is correct however, then what means of security is there between the client and the Web API other than communicating over HTTPS when the client has to send it's credentials to the Web API, so the Web API can authenticate and authorize the user against either Azure AD or IdentityServer?
If I understand your requirements correctly, then you are able to change the client Windows app, but unable to add external assemblies to it? So you would not be able to add the ADAL NuGet package to it.
You can still use Azure AD authentication - it is possible, but not trivial, to implement the client code yourself.
Or you can, as you already mentioned, pass the user's credentials to the Web API somehow, and then use that to have the Web API do authentication towards Azure AD on behalf of the user. There is a sample app which shows how to use username/password credentials.
This however, goes against the whole OAuth/OpenIdConnect mindset, where your app should never know the user's credentials.
Here:
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/active-directory/develop/active-directory-v2-protocols-oidc.md
Be careful with trying to use the most recent version of the Azure AD endpoint (just don't use version 2.0, they shot themselves in the foot by excluding all Azure AD webapp registrations & by "securing" web APIs by making them only available to apps with the same appid - as far as I'm concerned, it's unusable until they fix those two issues) - see the "[!NOTE]" near the top of that linked page for the v2.0 limitations.
Here's the scenario
3rd Party App, with a back end. Customer uses the app.
Back end needs to access user's exchange information, assumedly via EWS
Back end is running in our datacenter/cloud, not customers.
Cannot require local administrator involvement
Want to avoid storing username/password in our back end.
Want to support both Office365 and on-premise.
I believe this is currently impossible, but wanted to verify:
Impersonation would be a great way, but requires Administrator
Token based authentication is not used for this. It is for a mail app to use for SSO to the backend, not for the backend to access Exchange.
OAUTH would be ideal, but is a) for Office365 only currently b) requires a portion of the back end to be hosted by Azure c) The Azure install has to be linked to the Office365 install and is for the local administrator only.
Is my analysis correct? Any options I've missed?
You're mostly correct. OAuth is currently for Office 365 only, so that would rule out on-premise. However, with OAuth you do not have to host your back-end in Azure. You would need an Azure tenant to register your application, but the app itself is not required to be hosted in Azure. If you use EWS, then even with OAuth you will need some admin involvement, because EWS requires a permission scope that requires the app to be registered in the target tenant, users can't consent using a registration from another tenant.
If you use the REST APIs, which are in preview, you wouldn't need an admin's involvement, users could consent for themselves. That would get you almost where you want to be (assuming the REST APIs provide the data that you're after), but wouldn't support on-premise.
So to add to this mostly correct answer from Jason:
using pure rest, you need only create a "multitenant" application and users can self-consent.
You can also use an OAuth token to authenticate to EWS - but only if the delegate Full Access To Mailbox is selected. This also doesn't require admin consent but is a big scope (but necessary because EWS doesn't understand scopes)
I'm trying to write a C# console app that will register an application in Azure Active Directory. It should work just as the web application project creation wizard in VS 2013 when you Change Authentication and select Organizational Accounts in Azure.
Following the fiddler trace, I can see that it authenticates the user using wsfederation and an oauth2 token and then uses the graph.windows.net graph api to configuration the AAD directoryObjects service principal and application.
I have tried to use the sample Graph API app, but it requires the app be registered first so that I have the clientId (application id) and password (key) to send in the Acquire Token request using the Windows Azure AD Authentication Library for .NET.
I've tried using a bunch of the different Azure APIs but they all have my chicken and egg problem, I want to use an unregistered client application to register an application in AAD. I need to avoid Configuring Application Authentication and Authorization for the Graph API so that the user has no manual steps.
Does anyone know how Visual Studio does it, using just the user login with browser prompt or if there is a standard application id and password that can be used to access the graph API, like there is the standard login URL, https://login.windows.net/common? Some C# samples would be greatly appreciated.
This post does the Application creation, but requires a clientId and password, which I don't think I have.
You can't register a new application using the Graph API from an unregistered client. The only reason the VS2013 flow works is because VS2013 is already registered in a special way within Azure AD -- it's a first party application and has unique permissions. In my Fiddler trace, VS2013 uses a client ID of 872cd9fa-d31f-45e0-9eab-6e460a02d1f1. Technically you can use this client ID and the redirect URI of VS2013 to initiate sign-on with Azure AD. This still involves user interaction (the user has to authenticate via browser pop-up) so it doesn't meet your requirement for "no manual steps," but it's somewhat helpful for understanding the protocol flows and how registration works.
The bottom line is that if you want to call the Graph API without user interaction (client credential flow), the client needs to be registered with the proper application permissions.