I have a SharePoint Online application that access an API the reside outside my network and one of our Azure. This API is accessibly through public. I am using this API to access data in my SQL server, with this I am worried that my API is not secure and I am wonder what are the things I can do to secure my API so that no only users logged in to our SharePoint can use it.
There are several ways in which you can secure it. These ways vary in complexity and each have their specific considerations.
Secure an API with Azure AD
If you're using Office 365, securing custom APIs using Azure AD is an architectural option that you should definitely consider. First and foremost, it allows you to secure the access to the API using existing organizational credentials that are already managed through Office 365 and Azure AD. Users with an active account can seamlessly work with applications that leverage APIs secured with Azure AD. Azure AD administrators can centrally manage access to the API, the same way they manage access to all other applications registered with Azure AD.
More info: here
Related
We currently have Azure Active Directory with several thousand users in Active Directory. What does IdentityServer4 provide that I cannot get with connecting my .NET and/or Java apps to AAD alone? Can AAD provide me with an auth token that can be used to access the front-end app as well as the back-end API?
The key benefit is control (you can model your clients and resources and taylor your UX as you see fit) and the ability to use it as a federation gateway. E.g. if you need to support multiple customers many of which may want integration to their own IDP.
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.
I'm currently developing a API to commercialized in a B2B SAAS fashion.
The goal is to authenticate the worker of the company. We have an SDK that should be able to do that. There is the possibility to force each user to set credentials specific for our service, but that will hurt integration with companies applications.
The idea would be to have some kind of authentication (client independent) that make it easier to authenticate users.
The question is: There is a easy way to create an automatic process that does not depend on the client type of authentication methods, for this type of task?
Thanks in advance.
Have you taken a look at Azure AD? It specifically supports multi-tenant scenarios.
Tenants can use Azure AD Connect to sync their on-premise directory to the cloud. Clients can use ADAL to acquire a token which your service trusts. The issued token contains a tenant-id claim indicating via which tenant the user logged in.
Just to add to MvdD answer, in Azure AD support three ways to sign in:
Federated Single Sign-On enables applications to redirect to Azure AD
for user authentication instead of prompting for its own password.
This is supported for applications that support protocols such as SAML
2.0, WS-Federation, or OpenID Connect, and is the richest mode of single sign-on.
Password-based Single Sign-On enables secure application password
storage and replay using a web browser extension or mobile app. This
leverages the existing sign-in process provided by the application,
but enables an administrator to manage the passwords and does not
require the user to know the password.
Existing Single Sign-On enables Azure AD to leverage any existing
single sign-on that has been set up for the application, but enables
these applications to be linked to the Office 365 or Azure AD access
panel portals, and also enables additional reporting in Azure AD when
the applications are launched there.
I am trying to evaluate a strategy where I can integrate our Azure based application to SharePoint Online.
The idea is to provide seamless UI so that they are able to use the best of the features from both these applications without having to navigate away from our application.
We would like to bundle the application with Sharepoint online so that if a user comes to our application they will see another tab for collaboration which will open SharePoint online in a seperate iFrame or something like that.
However the issue here is that we do not want the user to keep another set of user credentials for SharePoint online. Is there a way where we can provide some kind of single sign on here.
Our application uses forms based authentication.
I could verify that you sure can use ClaimBased SSO with Azure and SPOnline. Look for the following:
Claims-Based Single Sign-On for the Web and Windows Azure
Remote Authentication in SharePoint Online Using Claims-Based Authentication
So using Claim Based Authentication (Use Windows Azure ACS) you can merge SP online and Azure Web Role together.
We are looking to host our product on Azure- the intent behind using Azure is that we get to focus on the core product, and are fine with the standard cloud features that Azure offers without needing to understand too much of the internals- not exactly the power users!
One thought was that if Azure had an authentication functionality- profiles, logins, password reset/ reminder etc, it would save us time from building what is essentially a commodity
Any guidance on this?
Azure offers the Access Control Service, which is a Federated Authentication service. It's already preconfigured with support for Live ID, Google and Yahoo authentication, but you can also add your own security token service (such as ADFS).
Windows Azure does not have a built in login feature. However,App Fabric Access Control Service(ACS) does; see the ACS tutorial here for example usage.