I've published a WPF application with ClickOnce with internet connection required.
Is there any way to control who can connect to the application?
Let's say the app needs a subscription system to be used, and if the client doesn't pay, the application can't start.
Administering ClickOnce Deployments
Even though there are no built-in mechanisms with ClickOnce to determine which users are trying to deploy your applications, there are a number of approaches you can employ to obtain this information. These include:
Windows authentication over HTTP(S).
Custom authentication designed
into the application.
Passing query string parameters when launching
the application (requires dynamic manifest generation with embedded
user credentials for installed applications).
Custom client proxy and
custom HTTP module authentication.
I ended up choosing Custom Authentification methods to control who can enter or not into my application.
Related
We have a .NET Core web application with an AngularJS SPA front-end. We also have a Power BI Report Server with a few dozen Paginated Reports (SSRS). We would like for the web app users to be able to view/save/print the reports from the web app, without having to authenticate again into the Power BI Report Server. We also don't want to maintain two user lists (one for the web app, and one for the PBIRS). I have been told that they want us to use a single service account for PBIRS, and have the web app authenticate in to PBIRS, and serve up the reports to the user.
Unfortunately, Microsoft's official SSRS Report Viewer control (which allows you to enter authentication info), only supports Web Forms, which is not compatible with .NET Core. I have tried a few .NET Core wrappers for it, but I was not able to get them working.
Then I had another idea. Can I have my .NET code create a client, authenticate into PBIRS, and maybe get an authentication cookie, then somehow attach that cookie to the user's browser, so that if the user goes directly to the PBIRS, the cookie is valid and they are authenticated in as the service account user? How can I do this?
These two servers might be in different subdomains, but I think they will be in the same domain. I need to verify this. I think it might not be possible at all if they are on different domains, correct?
I'm trying to develop many projects under one solution on asp.net and I want to be authenticated just on the first project (Demarrage) then having authenticated immedialtly in the others projects. I'm using Windows authentication.Project Overview Link
As far as I know, if you enable the IIS windows auth and use IE or Chrome to access the web application. The browser will auto store the windows credenticial and use it to login in. That means you just need to login in once and it could access other web application.
If you want to enable a SSO for both windows auth and other auth mode. I suggest you could consider using identity server. The Identity server is an OpenID Connect and OAuth 2.0 framework. It could Single sign-on (and out) over multiple application types and it support windows auth.
Details about how to use it with windows auth, you could refer to below article:
http://docs.identityserver.io/en/latest/topics/windows.html
I am completely a novice about Asp.net and Azure platform. I created a simple web application in VS2013 and deployed it to Azure web application. When I try to open my url (xxx.azurewebsites.net) it shows me a login page that my local application does not consist.
I digged some info about it, but due my knowledge level of web development and Azure platform, I did not understand the problem. It seems Azure Active Directory should be used, but I am not certain about it.
My question is, is there a way to skip the login page? If not, how can I define credentials to my application to be accessed?
Thank you.
As far as I know, Visual Studio 2013 offers several authentication options (No Authentication, Individual User Accounts, Organizational Accounts and Windows Authentication) for the Web Forms, MVC, and Web API templates.
According to your description, it seems that you select Organizational Accounts option for your application, which will configure the application to use Windows Identity Foundation (WIF) for authentication based on user accounts in Azure Active Directory (Azure AD, which includes Office 365) or Windows Server Active Directory. If you don’t want authentication for your application, please choose No Authentication option when you create the project.
We are building a web application that also includes webAPI's. These WebAPIs needs to be exposed to other applications as well (other internal application on different subDomain or 3rd party application). We are thinking of using OpenId Connect, so that not only we will be able to give access_token but also id_token for authentication.
Now the question is 'Should my main application also use openId connect' for authentication/authorization. I am not in favor of this. As per my understanding, only external applications should use openid connect to use main application's resources. And internal applications (main as well as application on different sub-domain) can work with regular cookie based authentication.
For instance, main application is MyWebApp.com (this includes webapi as well). Other internal applications are maps.MyWebApp.com, admin.MyWebApp.com, payroll.MyWebApp.com.
Other 3rd party application could be OtherWebApp.com.
Please suggest.
"Should my main application also use openid connect?"
Advantages
- paves the way for single sign on
- modularizes your authentication so you're not implementing different authentication solutions.
- you have the option of using the same Web api from your main app. (although you could just use the oauth2 client credentials flow and simply skip the openid connect authentication part)
Disadvantages
- if you only had one client app then this could be overkill
- you're adding complexity to the app by making it depend on an authentication server app (but modularizing has advantages too)
I don't know your scenario completely but I'm inclined to say yes. Although, I'd definitely turn off the consent screen from oauth2 for your trusted main app. If you don't use openid connect for authentication, it shouldn't be too hard to convert your main app to use it later
We have rewritten a WinForms app A as a web app. The old WinForms app had integration with WinForms app B, in that you could fire it up from app A with a set of variables.
Users are now demanding the same functionality from a rewritten web app. My first thought was for WinForms app B to create my own URL protocol (foo://...), but it seems that to do that you have to create keys in HKEY_CLASSES_ROOT - which is an activity done by an admin user. However, the users are basically limited users and WinForms app B is actually a ClickOnce app.
What are my options?
Since App A is now in the cloud and the user interacts with it via the browser, it is sandboxed and many of the things that a desktop app can do are not available to it anymore.
This is a security feature and outside of writing a browser plugin that will bridge between App a on the browser and App b, there isn't much you can do.