I have a Silverlight RIA application that uses Forms authentication. We want to pass users of a certain domain through Windows authentication and if that fails or user is not part of that domain it falls back to Forms authentication.
Most of the stuff I've found was for aspx sites using methods not available in Silverlight. Many others say it isn't possible. Has anybody managed to do this without to much trouble?
The app is based on the Silverlight Business Application template in VS2010 (SL4).
I don't think this is possible. Ran into the same issue and decided to turn off windows authentication.
See:
http://forums.silverlight.net/forums/t/228703.aspx
http://connect.microsoft.com/VisualStudio/feedback/details/566410/enable-wcf-ria-services-with-forms-authentication-and-integrated-windows-authentication
The second link seems to indicate this is a bug that may be resolved in a future release
Related
I am implementing a WebApp in our company's intranet with Blazor WebAssembly. I need to make API-Calls to our DevOps Server hosted in our intranet and need to use Windows Authentication to access the API. In the former used WPF Client it was enough to just add the UseDefaultCredentials-Flag on the HttpClient, but that does not work in WebAssembly anymore since the App is running in the browser. The Microsoft Docs state We don't recommend using Windows Authentication with Blazor Webassembly, but not recommend does not mean not support, so it has to be possible somehow, to attach the current App-User's Windows Credentials(Token) to the API Call. Unfortunately there exists no example on the docs page on how to implement this and I have not found any code on how to tackle this, although on some forums people wrote that it is possible, but did not include the How in their comments.
I am using .NET5 for both Server and Client and need to make the Api-Call with Windows Authentication from the Client, not the Server as most examples are using it, as my Server-Project uses the same User for all Requests but I need the User of the Client-Project.
Any kind of help is appreciated.
This question has been asked so many times, and a quick search came up with lot of results. But I haven’t gotten satisfactory answer yet.
We have 2 web applications ( and we may have more in future) App1 is .Net 4 Silverlight Application and App2 is Node.js/Angular application. Both applications have different domains. www.app1.com and www.app2.com The App1 is hosted in IIS and App2 is NOT in IIS
Now, we have to implement Single Sign On Feature to support these applications. I was looking into ASP.NET Identity which is available in .Net 4.5.
Questions
1. So I thought of creating new MVC 5 application using .Net 4.5 that could serve as SSO site. If possible I wanted to use our own SQL server to maintain the credentials. But I am not sure how to share authentication ticket/cookie between sites. I have done this before using Forms Authentication where I had to use same machine key on all websites. But those were all .net applications. However with new identity framework and OWIN and with different types of applications i am not sure. So before I jump into it and start developing I wanted to know is it recommended approach, and if yes, can someone point me in the right direction. An article would greatly help.
2.Second options is to use Azure AD, but I am assuming we have to pay for it( we have MSDN sub) and we do not have local active directory either. Is Azure AD is the right option here? Does it work with Node.Js/Angular application. With Azure AD I guess App1 I may have to upgrade it to .Net 4.5
I should like to control my old vb.net application also via web.
I should like to duplicate few labels/texts and few buttons/checkbox to control some parameters, simply connecting with a browser to a web page. (Not with Ultravnc or similar)
So, Adding a web interface at the existing project.
I'm note able to find the method to follow.
Can you help me?
Thank you
It sounds like you want to create a VB.net web project.
You'll need to create a new web project for that. You should also factor out any business logic into a separate assembly so it can be used by both the winforms and web application.
You can make connection between your desktop application and web application with this code.
Classic Asp (as I understand it) is not really “encouraged” by Microsoft (e.g. there is no classic ASP project in VS) and essentially is a collection of asp pages that contain HTML and some kind of scripting. There’s no .config file as such.
That being the case., can classic ASP sites be integrated into WIF?
How do you “force” the application to authenticate using a STS? (There’s no .config file for FedUtil to change).
How do you approach the problem of a large customer that still has a lot of legacy classic ASP sites and wants to move to federated authentication using a STS?
P.S. There is a reference on the Internet i.e. “In IIS7 you select the URLAuthorisation Module and untick the use for managed code only setting. I have used this to protect static files and a cgi exe, so I assume it will also protect .asp files too”.
I’m still confused as to where the STS comes into this solution? How does IIS 7 know where the STS is?
The issue here is that as you are using ASP, IIS doesn't run in pipeline mode. Therefore, it won't execute the HTTPModules required by ADFS. (Or any .NET httpmodules...)
In your case, I have two idea (both aren't pleasant, I am afraid)
You could implement the WIF protocol in ASP. It's documented. Well, you certainly could do it, but beware of errors in your implementation, which could damage the security of your application. The bright side is that you will be able to leverage all the WIF goodies in your apps.
You could attempt to host CGI/ ASP in an IIS HttpModule, in pipeline mode. Perfs would probably decrease, and you would need to send to CGI all the required request infos (and server parameters). It was the idea of this guy. I don't know if he succeded.
The first proposition is probably the good one. Hem. Good luck, WIF isn't a trivial piece of code. (Even if understanding the protocol is not very difficult. As always, hell lies in the details)
I want to make use of some of the ASP.NET 3.5 capability within SharePoint 2007. In particular, I want to do the following:
Provide REST and maybe JSON through HTTP so that another product can consume SharePoint content.
Provide AJAX web parts within SharePoint. These will probably have little to no server side controls. Most content will be loaded using Javascript and hitting an external system (primarily not SharePoint) over HTTP that provides REST or JSON.
Provide this capability as a product. This is not a one-off solution for a single implementation.
My main concern is push-back from IT groups not wanting to change their SharePoint environment to allow for the product to work. So, I'd prefer to be able to say that what I'm doing is "supported by Microsoft", but I'm not sure that will be the case.
I realize that I could create a separate (non-SharePoint) web site on the SharePoint server(s) for WCF endpoints that provide SharePoint data to an external application. I would rather not do this because that won't help my web parts (if they need help) and that makes deployment harder. Proper SharePoint deployment will automatically have SharePoint update all necessary files (e.g., web.config) on any new web front end added to the farm and this wouldn't follow that pattern. In addition, I'd lose the ability to use SPContext.Current.
I have read much of Daniel Larson's book on Developing Service-Oriented AJAX Applications on the Microsoft Platform (good read, BTW), esp. Chapter 11 on extending SharePoint. He outlines WCF, ASMX, and HTTP Handler options and for the most part recommends the HTTP Handler option. It appears that the HTTP Handler option has minimal changes to web.config.
I have also seen a blogs on SharePoint as a WCF Host, SharePoint 2007 and the Thin .NET 3.5 Development Model, How to: Get up and running with .NET 3.5 in your SharePoint environment, and Enabling .NET 3.5 in SharePoint 2007 Sites, the Lazy Way. As well as the "Silverlight (.NET 3.5) Config Feature" (and maybe even the "Ajax.Config Feature") in the SharePoint 2007 Features CodePlex Project. It seems that all of these options do some fairly drastic changes to the web.config and may not be acceptable to potential customers.
What are the opinions out there on this? What about if I want to use the AJAX Control Toolkit (I've used this before in SharePoint, but it has been a while)?
Note that we probably could require SharePoint SP2 if that helps, but I don't think it does.
Note also that Silverlight is not a requirement for the SharePoint web parts, but allowing for it might be nice.
Your first point could be solved by a custom wrapper to the SharePoint web services, presenting the API that you want to present, rather than the generic web service.
Your second point, AJAX enabled pages and web parts, is already possible - how to enable AJAX in SharePoint.
.NET 3.5 Is supported in SharePoint (as of SP1 I believe), However you will not be able to get away from making web.config changes and installing .NET 3.5 on the servers - it will likely only be there if there are already AJAX web parts in use.
Aside from that what you are looking at is largely independent of SharePoint - If you can build something as an aspx page or asmx web service you should be able to deploy it to a SharePoint site.
If you want to avoid 3.5 installation issues altogether you should be able to build something totally separate - jQuery for the web parts (no server side components needed) and for getting data out of sharepoint build something that translates calls to the standard web services into a friendlier interface.