I have a web role project in ASP.NET made for Azure deployment and need to have authentication.
I have to choose between Office 365 and On-Premise Active Directory.
Looks like both needs to be integrated to Azure Active Directory using Access Control Service.
What are the pros and cons of both?
Also if there are any other possibilities.
As astaykov mentions in his comment on your question you are not restricted to involving Access Control Services in this scenario. Not sure why he didn't submit that comment as an answer.
If you truly must go against your Office 365 or On Premise AD then what you are really saying asking is what is the difference between the two. I'll list some thoughts, but first if you want to implement these then here are some links:
Offerings from MS on Identity: http://msdn.microsoft.com/en-us/security/aa570351.aspx
Using ADFS V2 in your Azure Deployment:
http://channel9.msdn.com/shows/Identity/WIF-Workshop-9-WIF-and-Windows-Azure/ This is a little older material and I couldn't find much on using WIF to connect directo ADFS V2 that was more current. You do NOT have to invovle ACS in this at all. Sadly, this was misunderstood a lot when ACS was released.
Using Office 365/Windows Azure AD: http://msdn.microsoft.com/library/windowsazure/dn151790.aspx
Note: I have connected Web sites running in Azure to ADFSV2 directly, but I've not had a chance to work with the WAAD/Office 365 stuff yet.
If you choose to go with exposing your AD on premise then you would likely do this by exposing it using ADFS V2. This is what opens up the endpoint for the code running WIndows Identify Foundation (WIF) objects to reach out and deal with authentication. The upshot of this is that you don't have to worry about Office 365 logins or a WAAD separately and might be an interesting choice if you don't have those services for ANY OTHER reason but this one scenario. The down side is that you are exposing a proxy to your AD on an endpoint at your own location. If you lose connectivity to the internet then no one attempting to use the apps in the cloud would be able to authenticate. This is also the option I might look at if the users of the app in the cloud will ONLY EVER access it while behind your firewall (such as being at an office or even over VPN). This is because you can set it up so that your app uses a ADFS endpoint that is NOT exposed to the internet, but if they are behind your firewall it would still work. This pretty much ensures that only people already behind your firewall can use your app.
If you choose to use Office 365/WAAD integration then the upside is that you can sync with your onpremise AD to give single sign on to resources on your network as well as to the apps in the cloud. You also make access to your cloud apps more resilient because they have no need to depend on your exposed ADFS V2 endpoint. If you use Office 365/WAAD for any other reason (such as your employess use Office 365 for email, collaboration, etc.) then this is the option I would look at first.
You should look at ACS if you want to integrate with other identify providers such as Google, Facebook or even other companies. Technically you wouldn't have to use ACS at that time either, but it will certainly save you a ton of work to use ACS and not write the integration code on your own for each provider.
Related
Sorry no code here because I am looking for a better idea or if I am on the right track?
I have two websites, lets call them A and B.
A is a website exposed to the internet and only users with valid account can access.
B is a internal (intranet) website with (Windows authentication using Active directory). I want Application B (intranet) to create users for Application A.
Application A is using the inbuilt ASP.NET JWT token authentication.
My idea is to expose a Api on the extranet website (A) and let (B) access this API. I can use CORS to make sure only (B) has access to the end point but I am not sure if this is a good enough protection? We will perform security penetrations test from a third party company so this might fail the security test?
Or
I can use entity framework to a update the AspnetUsers table manually. Not idea if this is feasible or the right way or doing things.
Any other solution?
In my opinion, don't expose your internal obligations with external solutions like implementing APIs etc ...
Just share the database to be accessible for B. In this way, the server administration is the only security concern and nobody knows how you work. In addition, It's not important how you implement the user authentication for each one (whether Windows Authentication or JWT) and has an independent infrastructure.
They are multiple solution to this one problem. It then end it really depends on your specific criteria.
You could go with:
B (intranet) website, reaching into the database and creating user as needed.
A (internet) website, having an API exposing the necessary endpoint to create user.
A (internet) website, having data migration running every now and then to insert users.
But they all comes with there ups and downs, I'll try to break them down for you.
API solution
Ups:
Single responsibility, you have only one piece of code touching this database which makes it easier to mitigate side effect
it is "future proof" you could easily have more services using this api.
Downs:
Attack surface increased, the API is on a public so subject to 3rd parties trying to play with it.
Maintain API as the database model changes (one more piece to maintain)
Not the fastest solution to implement.
Database direct access
Ups:
Attack surface minimal.
Very quick to develop
Downs:
Database model has to be maintained twice
migration + deployment have to be coordinated, hard to maintain.
Make the system more error prone.
Migration on release
Ups:
Cheapest to develop
Highest performance on inserts
Downs:
Not flexible
Very slow for user
Many deployment
Manual work (will be costly over time)
In my opinion I suggest you go for the API, secure the API access with OAuth mechanism. It OAuth is too time consuming to put in place. Maybe you can try some easier Auth protocols.
We configured Azure web app infrastructure such way that consist
customer web portal and WebApp API site
Scenario: when a user accessing a customer web portal where all requests communicate from Web API like (GET, POST, DELETE, PUT).
Here actually the problem is Web API portal is publicly available for now (but I don't know about for what extent Web API visible to users publicly still requires or not?).
In our case Customer ----API call should be in internal communication only there no third-party vendors supply.
Is there any methods secure the cus--API.
We tried to secure cus---API azure network restrictions in Web API network settings but that not helps us (we got stuck the complete cus--API communication is blocked)
As I mentioned Web API hide from the internet then we applied Azure AD authentication for Web API.
In this case, we got results were negative
we have no prior knowledge from code level securing and communication token generation
Finally, we looking for suggestions, and suggest me what are security checks to WEB APP-API COMMUNICATING WITH CUSTOMER PORTAL. WHAT ARE SECURITY CHECKS THAT NEED FIGURE OUT?
Another big problem is really WEBAPP-API put publicly if yes then what are the ways to tighten security.
Please share ideas and suggestion it would be greatly helpful to us.
Thank you
I have successfully deployed a Google Cloud Endpoints Developer Portal for my API running on Endpoints. I would like to provide access to testing to people outside my organisation that are not using GCP in their projects.
Login to the portal works correctly if I enable the Service Consumer role for these people (on per-email basis). However, when they open it for the first time, they are being asked to grant some extra permissions to the portal:
This form can create totally unnecessary security concerns. Does anyone know, why is it needed?
I only would like my clients to be able to test my API using a GUI, before they could start connecting their projects (not necessary on GCP) to mine. This seems to be a valid use case for me, however I might be misunderstanding some basic concepts.
Or should I submit a feature request to Google about a new role that only enables the access to the portal, and nothing else, so no such forms are shown?
Since Endpoints APIs must be explicitly shared with customers, the portal needs to verify that the logged-in user has permission to view that Endpoints API. So the short answer is that these scopes are being requested primarily so the portal can check the user's access to this API.
Longer answer is that we (the Endpoints team) are looking into if it's possible to build narrower OAuth scopes that would correspond to the access checks we perform. We agree that it's unnecessarily broad of an access request and are hoping to improve this in the future. Thanks for your comment!
(note: To address a criticism I've deleted a prior question and reposted this more succinct version)
I'm trying to compare AWS and Azure for a custom web app that's essentially like any canned content management system. It requires web hosting, database, email, storage, security, some way to process ASP.NET but with high availability and load balanced.
The PaaS/IaaS distinction can sometimes be grey (in part because companies tend to use marketing jargon that portrays IaaS type services as maintenance free). From a small business perspective its quite clear though. If a service involves the SMB spend time maintaining rather than developing, its in the IaaS camp. Since I'm a single developer with limited time, a PaaS model for all services would be preferable. The ideal would be all services (web hosting, database, email, etc are offered as a zero maintenance scalable service rather than have to spin up and manage individual instances.
I find AWS can do everything but a drawback is that one still needs to manage instances (i.e. I would need to keep the software on instances updated, track instances, manage network, security, etc.) S3 doesn't process scripts. AWS Beanstalk and Optworks are still essentially mostly helper apps for starting up an IaaS type environment. (whereas say DynamoDB would count as a PaaS type service). Recently Microsoft has dropped prices on Azure which makes it an attractive alternative
In short, I am looking for a list of services offered by Azure which are actually no maintenance services that don't require I patch software or need to spin up instances to handle traffic spikes (e.g. web hosting, script processing, database, email, etc..)
Pretty much every Azure service besides "Virtual Machines" is PAAS. Meaning, it is fully managed by the platform and users only end up configuring startup and runtime behavior upfront.
This includes but is not limited to:
SQL Azure, Azure Storage, Media Services, Cloud Services, Websites, Cache, Service Bus, Identity, CDN, etc.
Azure was built with PAAS first mindset and IAAS only came later.
In addition check out this page that explains the 3 flavors of virtual machines you can get in Windows Azure (web site, cloud service and virtual machine). It gives you a good understanding on their differences and which one to pick depending on the level of control you need.
Actually in Windows Azure PaaS are: Web Role and Worker Role - because they provide out of box integration with IDE, framework for development of background jobs and web applications.
I'm a newbie with ASP.NET Web API and I heard so much about it that, it's the new industry standard and all, I've decided to build a regular hotel management system with it. I created some models and generated controls and created database using code-first migration. It all was tough at the beginning but now I've got hold of the essence. It's Awesome.
Now I'm stuck at the user management level. According to Web API spec there are options to manage access to resources like basic, Forms, integrated Win and OAuth. And also something about 2-legged and 3-legged which I understand are all authentication options which involves another data source or app (may be not the right terms) that will handle the authentication on behalf of the Web API I build.
Since my application is simple (for now), I was thinking is it possible to allow the Web API to include the necessary authentication, for example authenticating (user) and authorizing (role) before giving access to the data, thus seliminating the "LEGGED" dependance but at the same time it is open to allow 2-LEGGED and 3-LEGGED implementation in the future if I wish to.
From what I've seen and read the Web API is not ideal for a system like what I'm developing. Hope I'm wrong coz I find it awesome in terms of a service that can be consumed by other systems.
In my mind the big picture for the system is to allow customersI and third parties to access
hotel information via web and smart phones to check room availability and book rooms
restaurant information ...
hotel events, spa..etc
Please advice, to achieve this, how do I go about implementing authentication and authorization?