We recently moved an Azure subscription from one tenant to another while consolidating all our subscriptions in one tenant. Unfortunately, this broke Managed Service Identity for all our Web Apps, and we are now hesitant to move our remaining subscriptions for fear of having to provision new Web Apps in order to get MSI working again.
Is there a way to prevent this from happening, or at least a way to delete or reset the identities created by MSI so we can recreate them? That would lead to a little bit of downtime, but that would be preferable to having to come up with new names for all the Web Apps, as that was ultimately the solution we found to getting new identities.
Of course, we would prefer to avoid any downtime at all, but I realize that moving a subscription between tenants (and their directories) is tricky.
Filip, thank you for reaching out. We're currently investigating how to make the subscription move a smoother process for MSI enabled resources. Please send me a mail, and we can chat further: ArLuca#microsoft.com
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.
Suppose we have a site on Google Firebase Hosting that routes some requests to a Google Cloud Run service. The service is considered entirely an implementation detail and its only client is the single website. The only reason for using a Cloud Run service is that it is the only suitable technical option within the Firebase platform.
Now, suppose that the API of the service may have a breaking change with every update, so the Firebase Hosting content must change too. How do you update or roll back both parts together so as to avoid incompatibilities?
Straightforwardly, we can update the service and the site content in separate steps, but that means some requests from the old revision of the site may reach the new revision of the service or the other way around, causing errors due to API mismatch. The same issues are present when rolling back the site content and the service at the same time.
One theoretical solution would be to deterministically route requests to different service revisions based on revision labels, but that is not supported on Cloud Run.
One realistic solution would be to create a new service for every update of the site content. However, that would result in unbounded accumulation of services which are not automatically deleted like service revisions are.
Another solution (proposed below) would be to maintain backwards compatibility in the service - it would support both the latest and the previous API version. However, this can be considered an unnecessary overhead. Since the two parts (static content and the service) have no real need to ever be updated independently, it would be very convenient to avoid the overhead of maintaining backwards compatibility in the service.
For what I know there is no way to make this update in a single transaction to avoid this behavior you mentioned as Firebase and Cloud Run are different products.
Also a good Practice in API design is to allow Service Evolution this means that updating the API shall not break the apps consuming it and new versions of the app shall be able to evolve in a way that they can consume the current API.
Something that is done when a new API will not allow retrocompatibility is to have different endpoints this is why some APIs are apiName/V1/method and apiName/v2/method but in this case both versions of the API are deployed.
I have experience developing software and web applications and I have decided to do some freelance work on the side. Well, I met with my first client and they are requesting a relatively simple, custom system that (without being long winded) tracks client’s paperwork as it progresses through the business’s different manual processes. It is a small business that has about 10 employees, but all of the employees will interact with the client’s paperwork, therefore everyone would need access to the new system. When I say ‘track’ I literally mean that the employees will ‘check as complete’ on a simple page the increases a progress bar at different stages for the paperwork. Now I am %110 capable of coding the custom system that meets their needs, but I am unsure about how I should go about doing it.
The information that is being tracked in the new system and stored in the DB is confidential information that they are very protective of. My main question is how should I be developing this to be as secure as I can?
-They have their own server in house, so should I develop an application (VB and SQL) for the server and require employees to log on remotely to use it? Can more than one person access/use the application at a time?
-Or should I develop a web application (ASP.Net/VB and SQL) that is only accessible on their network to their employees? They plan to expand offices, could they set up a VPN to access the site?
I’m leaning towards a web application, but I have not done too much in term of security. Basically I’m looking for pros and cons for either option or any suggestions on what I should.
PS, stackoverflow is awesome! Long time user, first time poster!
If you want to develop using vb & sql you have to consider that:
You need to have real ip
Your system will communicate threw certain port and you have to handle the security measure for letting certain port opened in your server.
You should have good knowledge in network programming
If you want to develop using asp.net you have to consider that:
in case only office employees will use the system, you can develop against users in Active Directory and for outside users with username and password with SSL connection or vpn
for preventing more than one person access the file you can simply add column 'locked' in case file is being used.
Well im not a web fan (I suck) ive seen too many security issues go with it...i.e Lulzsec, but i do very much love VB apps.
So I would definetely recommend a VB app connected to a MSSQL database (coz it's easy to configure and havent seen any security exploits yet),my Chinese friend told me there is a way to access MySQL free databases.Now, allow remote access but make sure your Windows Firewall is also configured properly do look at all angles of security.
If I remember well there is an option in MSSQL to specify the IP addresses or is it MAC addresses that can access the DB so maybe input all of the 10 employees' IP addresses assuming they are static,if they are dynamic (DHCP) don't bother. And ask them to make the IP address of the server where you will host the DB on static.
If only 10 employees use the DB then limit the connections to 10. For now develop this when it comes to VPN you can make a Remote version of the App im sure that will come later right now focus on the basics. Also use Dotfuscator when you are publishing the app I heard it is very good.N also im suggesting the document/work order is received at the reception so that user will check in the document with specifics...if they are passing on the work order to the next user they should select the user and then THAT user may enter some sort of verification code unique to the user...im sure you can envision the rest from here. Now do I also get a cut from this?lol
I've been doing the same for years now, and I always take the website side, this days I go width ASP.NET MVC 4, it's easier, everything in their place and extremely easier to test and maintain.
The web application has a very big advantage to any standalone windows application, you deploy and upgrade only one application instead to maintain all the different versions once you start deploying windows apps, and they are harder to debug once you start to having different machines with different versions and so on...
so, Web or Win app = Web app, always!
All you need is a server that run IIS and set it up for using Active Directory (Visual Studio has that project already, simply create an ASP.NET MVC and choose the "intranet" template), it will set up everything for you, and all you need later is tweak the Active Directory connection string.
I also use a self-signed SSL to protect data between client and server, as I also make the apps available outside the office without VPN needed, as long as they login with their secure AD credentials.
And... audit everything into a secondary database, every action performed by a user since they login until they logout, every view, update or creating data witch .NET makes it simple if you create your Logging method to simple log messages and Stack messages on errors.
This will greatly benefit your employer and you when something goes wrong.
I would say to go with web application. Advantage using web application is, if they want to expand bussiness .. same can you do with you WebApp. But choose .Net over VB, going with latest techonology will help you resolve current challanges.
I am looking into different ways to handle updating an ASP.NET application across many different clients, and looking for suggestions from your previous experience.
We need the client apps to check if they have any available updates.
A way to Auto update (If possible, something similar to chromes but for webapp).
Some way to check that we are the ones sending the updates. (Checksum of some sort I would guess)
Any other tips/advice
Thanks
Edit: after thinking more about this overnight, I would have to agree that auto updates may not be the best. However maybe something more along the lines of how wordpress does it. Wordpress will display saying that there is an update available then clicking will auto update the system.
I would absolutely not have your application auto update on clients (assuming you mean clients are entities external to your organization) servers. We would immediately stop using a product that would "phone home" and update itself. Clients need to be able to choose when and how an update on their server occurs.
If you are going to do this, the easiest way would be to set up URI the systems could ping once a day etc. and see if there are updates available. If so the application would pull it down from the host system and update itself. If you do it using SSL then the certificate would verify the URI being hit is your company.
Having a hard time figuring out if you're actually talking about a web application or a desktop application. If you're trying to do something similar to Chrome...I'm guessing a desktop application. If that's the case...check out ClickOnce deployment.
It offers the first three bullet points you mention:
Every time a person runs the app, it will check for updates.
If updates are found, the user can choose to install them or not (better user experience than forcing the update on the user).
The application always checks the URL that the app was installed from...which in your case would be your servers.
If not, are there any fundamental limitations of the service that prevent one from being built?
In response to Garys answer. "If you're hosting your app on EC2, it'll be fine"
Even if you're hosting your application on EC2 you should not really use SimpleDB to store session state. It provides an "eventually consistent" guarantee, so if you PUT something there is no guarantee that you will see the item on your next GET.
see: http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/DeveloperGuide/index.html?EventualConsistencySummary.html
This is fine when you want to use simpledb to do indexing on data that does not need to be immediately up to date and can be reconciled later, but in the case of session state, you'd likely want something with ACID guarantees (like SQL Server) as you want to know that once you have committed something you will get it back on the next read.
This obviously depends on your requirements, but most people use session state to store shopping cart items or similar. Your site visitors will soon get upset if things appear to go missing from thier cart, then re-add them and then discover they have added the same item twice when they come to pay.
There's a C# library for working with SDB.
If you want to roll your own, the API, WSDL and other documentation can be found at http://aws.amazon.com/simpledb/#resources.
It's a pretty straight forward API that rides over HTTP. The hardest part is writing the signing code. There's plenty of implementations in other languages.
As for using it for session state, there's a huge speed difference between using SimpleDB from EC2 and anywhere else on the internet. If you're hosting your app on EC2, it'll be fine, otherwise, it'll be brutally slow.
You could base it off this MySQL provider:
http://harry-kimpel.spaces.live.com/Blog/cns!CAA619CB4C4D1B6C!342.entry