Is it possible to mix authentication types in a C# ASP.NET MVC web application hosted in Azure?
I have an ASP.NET MVC application written in C# that uses ASP.NET Identity as its authentication system.
A customer has asked if they can sign into the application using their Azure Active Directory (SSO using openconnect id).
I can recreate the application using openconnectid and assign their tenant as the AAD directory but users from my company can not log into the application because we do not exist in the customers Azure Active Directory.
We need to be able to log into the application because we perform data entry tasks for them using the web app.
Has anyone come across a similar issue?
Regards,
Graham
You may need to show login screen with 2 possible options. You redirect the user to their respective identity provider , they get authenticated and bring back the access_token/Id_token to access application resources.
Very much like different OpenID connect providers in the same application(FB, Google, Microsoft etc) and regardless of which provider user choose to get authenticated the token is same to access resources.
Related
Scenario:
I have an website developed in angular js and integrated with STS, while logging in I am presented with the STS login and after logging in with valid credentials - I am redirected to the main website. this far it is working cool.
To mention here, I have web api and wcf services which are hosted from within my website only, thus when the authentication is done at login - there is no issue in accessing the services as well (which are also protected by STS)
Finally we need to open SSRS reports from within the application using a report viewer control.
Challenge
The challenge we face here is that - due to the double hop
from STS authenticated Web app -> SSRS(windows authenticated) -> back to Services(STS authenticated)
SSRS fails to access the services. Locally we have made it work by creating a separate web api project which exposes the service links and is without any authentication.
However we need to ensure that the reports can be accessed only by users who carry a valid claim generated by the identity provider.
Is there a way the SSRS can be made to be a RP with a trusted relationship with the STS?
Any help will be highly appreciated :).
Our application is developed using asp.net and vb.net. It is a SAAS based application and is hosted with Rackspace
We need to implement Single sign on for our SAAS application, so that users of the application, users who will belong other corporate domains e.g domain1\abc.user and domain2\xyz.user can login automatically as long as they are logged on to their domain, as per above example user abc.user shall be automatically logged into to our application as long as he is logged into domain1.
Can you pl let me know it can be implemented
BizTalk Server uses Enterprise SSO which I have used in the past; there's no need to install (or buy, eeeek) BizTalk to use this: -
http://msdn.microsoft.com/en-us/library/ms972971.aspx
Hope that helps
I've been assigned to find a way of implementing SSO in our products. We have several Winform applications and one asp.net 4.0 web app (not MVC).
All the products are built using .Net 4.0, the web app is ASP.NET 4.0.
Some of the Winforms are commmunicating with our API via web services (asmx) and some uses our API directly. The web app is using the same API as well. We offer a set of web services (asmx) that uses the same API to external clients.
Currently we have our own authentication implementation (user, password, roles) in our systems and we would like to replace that with SSO. Or can these two authentication regimes co-exist somehow? The Winforms are used in intranets and the web app is used both in intranets and we also hosts the web apps for clients (accesible from the Internet).
The users are created in our system, but at the same time we import users from Active Directory using our own tool. Active Directory is really the primary user source.
I have read about Windows Identity Foundation and I wonder if I can use that to implement SSO. But what I don't understand is how to use WIF in the winform applications when they use the API directly.
What I would like to achieve is to remove all user administration from our system and use Active Directory as the user source. I guess that means using ADFS 2.0 to create claims, etc.
I can use .Net Framework 4.5 in this implementation (I know that WIF is now a first class citizen in .Net Framework 4.5).
Do you have any advices how to do this? Is WIF the best alternative to achieve SSO across winforms applications and web apps?
There is a way to get the WIF authentication cookie from within the WinForms application.
To do it, you just host the WebBrowser control and point it to the login page of your web application. Assuming the web application is federated with the ADFS2, the web browser control will automatically follow the flow - it will redirect to ADFS and stop there to show the prompt for user credentials (ADFS2 in Forms Authentication mode) or just authenticate using NTLM/Kerberos (ADFS2 in Windows authentication mode). Then the web browser will redirect back to your application.
This is where you hook your code. You just add a handler to the web browser's navigation event and you check when it comes back to your application AFTER ADFS2.0 authenticates the user. You can then call the InternetGetCookie method in the WinForms app to get all the authentication cookies issued by your application and you can close the window which hosts the web browser.
At this point, you have all authentication cookies issued by WIF (the SessionAuthenticationModule) for your application. You can now call your application web services and inject cookies into http calls. The web server will correctly recognize users as authenticated which means that all you have to do is to add proper authorization to your web services (the PrincipalPermission on your web methods should do).
An alternative approach would be to expose WCF services from your web application and guard them with WS-Federation active authentication. The downside of this approach is (in my opinion) that if your identity provider (ADFS) is further federated with yet another identity provider which DOES NOT necessarily implement WS-Trust/WS-Federation then the active authentication will probably fail (because the other identity provider does not implement it) while the passive scenario will still work (a bunch of redirects will sooner ot later end with a page which requires user to provide the credentials but the flow of authentication protocols between consecutive identity providers does not matter).
Here is my scenario -
1/ I have an ASP.NET MVC application running on my server, it uses Windows Authentication.
2/ There is different web application (written in Java) somewhere else that also uses Windows Authentication.
In the Controller of my MVC application I need to grab some information from this other Web app. How can I connect to the "foreign" application using the credentials of the user that is accessing my Controller?
Any help appreciated.
Impersonation doesn't leave the ASPNET process. This means that you cannot delegate the credentials and access a remote resource using them. You could either swap back to Forms authentication which uses cookies or you will need Kerberos.
We have an ASP.NET web application that we offer as a Service (it's hosted and it's accessible on the Web). We use Forms Authentication and our users have to enter a username/password to connect to our application. Some of our customers ask that we support single sign-on by authenticating users with their own Active Directory.
Our application has a different URL for each customer
www.ourapp.com/client1/
www.ourapp.com/client2/
www.ourapp.com/client3/
and each URL has its own web.config file (where asp.net settings can be specified and can vary for each customer).
What do I have to change in my ASP.NET application to support that?
What do I have to change on my Windows server configuration?
What will the customer have to do on his side to enable that?
Regards,
Check How To: Use Forms Authentication with Active Directory in ASP.NET 2.0 In short, you configure an ActiveDirectoryMembershipProvider to verify each username/password with the customer's AD. The customer must create an AD account for you that is allowed to perform the verification - which may be a problem with some customers. What's more, your code will handle the actual username/password used by users in their internal network, which can be an even bigger problem with customers.
A more secure solution is to use federation (using ADFS) or Claims Authentication using Windows Identity Foundation. In this case you "only" have to set trust relations between your domain and theirs.