I have a CRM instance that has been updated from CRM 2011 to CRM 2016 IFD. I have an old .net 3.5 website that was working just fine with CRM 2011 using a WSDL added service reference. Changes where required to the website to pass in credentials, now that it is IFD (ADFS 3.0). Those changes have been made. But since it is IFD, I need to change the WCF bindings to point use https and WS-Trust. When I walk through the SDK examples, it says I should be able to point to the Wsdl, to generate the WCF config. The Config is completely empty. I have been able to successfully do this with a 2011 CRM instance that is IFD (ADFS 2.0).
So how do I configure the WCF ABCs? Does CRM 2016 no longer allow this? Do I have a potential ADFS configuration issue (it is also currently requiring users to enter their user name and password when hitting CRM locally, even when on authenticated Domain Machines, so this is entirely possible.).
Therefore your looking to change your code to work with IFD in CRM 2016.
The topic of authentication is covered here:
https://msdn.microsoft.com/en-us/library/gg334502.aspx
You also likely want to look at oAuth as well.
https://msdn.microsoft.com/en-us/library/dn531010.aspx
Related
I don't have any code yet as I don't know where to start! I see on the web that I'd need to select
on the Access toolbar external data >> more >> data services. Then it asks to point to a xml config file. Which I don't have and would need to create. I have the connection string from a VB.net application.
sWIPConnString As String = "SERVER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=fake3465-vip.ent.agt.bb.ca)(PORT=41521))(CONNECT_DATA=(SERVICE_NAME=fictitious_service_name)));uid=APP_getinfo;pwd=thispassword;"
I'd have to convert that to an xml version. Any help would be appreciated!
Thank in advance
Pete
But those data services are not just any old plane jane web site. They are web sites that have installed, setup, and the developers of those web sites setup that data service connection. And these custom connections are NOT general web sites, and they are not general web services that many sites have. And they are not a web API written around say SOAP or some REST standard.
So unless that web site decided to adopt this Microsoft specific means and method to expose data, then you not be able to use this feature to simple connect to any old web site out of the blue. If you have a existing web site that exposes some web services? Then you have to use MSXML and consume that web data yourself. That option in Access is not some general purpose setting or feature that allows connection to any old web site - only ones that have created that web service written to the business connection options that Microsoft created.
It not clear if you planning to create some web services on the target web site (that would assume you're the developer of that web site), or you trying to consume existing web services that the given site exposes. Even in this 2nd case, those exposed web services or even REST calls has ZERO to do with the feature in Access.
so that feature is of only use for connecting to web sites that offer specific created connection based on that standard from Microsoft - it not a general web service consuming feature built into access and you can't use that feature as such.
How to make a web service call from Access? Well, it has ZERO to do with that feature. Here is a MSXML exmaple:
How to use XML web services in Access2007 which are built on Visual studio (2008/2010)
I currently have a Mobile Application that communicates through a WCF Service to access a Database. The Mobile App can access on the network as well as externally. It connects to the WCF Service which is hosted on one server inside the network. From there the WCF Service is pointing at another server which is hosting the Database that the Mobile Device is accessing.
With the above process how would you setup authentication using Active Directory which would confirm the user of the Mobile Application before it can access the WCF Service to confirm that the user is a member of AD and they can then login after authorization is complete. This would occur as the user opens up the Application. Would this be coded into the App to prompt for the information, then send the information to the WCF Service which would then allow access? If not this then are there any other ways or information/links that can be provided please?
Take a look at the BUILD 2013 videos. Visual Studio 2013 will create a webproject that will automagically do all that for you (I think). Just bare in mind, it uses the Microsoft.OWin.Security beta packages.
Also...you will need to install the AspNetWebTools2013 package first...
http://www.asp.net/visual-studio/overview/2013/creating-web-projects-in-visual-studio#orgauthoptions
I want to enable self-service for employees starting with the ability to update simple contact information into AD. The twist is that I want this as a web part in SharePoint Online as my company uses BPOS. Employees would log on, change their details and it gets back to the company's AD.
Initial investigations have shown that you cannot add custom web parts but you can add Silverlight components. I have found examples that work with SharePoint Online services and presume that I could reference an on-premise service that I've publicly exposed? This service would then work against the company's AD.
Any tips or direction would be appreciated.
The component that you add to SharePoint Online would have to communicate, via for example a web service, with an onsite component. That on site component would run in a security context of a user that is allowed to update AD.
Note be very carefull when you do this exposing a web service that can update your AD can be dangerous. You need to consider how the web service is secured and that the account used to run it has minimum required rights.
Investigation has found that you can reference your own service from a Silverlight component by nothing more than the usual 'Add Service Reference'. Make sure you have a CrossDomain policy file. You can work with the SharePoint Online services fine. Check out this
Can anyone give a clear explanation of the difference between using
clientCredentialType=Windows, and
clientCredentialType=Ntlm
in a server-side Web.config when hosting a WCF service?
I have a SOAP 1.1 (basicHttpBinding) service for interop with existing clients. It uses ASP.NET roles so needs clients to be authenticated.
When I am using the VS2005 (Cassini) server to host the service, I have to specify ClientCredentialType=Ntlm as above, and check the Ntlm authentication box in the project properties in VS2005. ClientCredentialType=Windows doesn't work - clients get a:
401 Unauthorized error
However when I'm running under IIS, it's the other way around: ClientCredentialType=Windows works, and ClientCredentialType=Ntlm fails.
Can anyone explain this, and preferably suggest a way I can have the same web.config file to run the service in Cassini and IIS?
Update
I have .NET 3.5 SP1 on my dev machine, which is XP SP2 running in a domain. Cassini therefore runs under a domain account, and IIS 5.1 under a local account.
I wonder if it could be related to the breaking change in .NET 3.5SP1 described in these articles.
http://www.aspnetpro.com/newsletterarticle/2008/12/asp200812ab_l/asp200812ab_l.asp
http://msmvps.com/blogs/alvin/archive/2008/11/14/net-3-5-sp1-breaking-change-to-wcf.aspx
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=354236
The situation sounds similar as clientCredentialType=Windows fails when the server is running under a domain account (which is my situation with Cassini - running as my normal domain user account), and works when running under a local account (which is my situation with IIS).
The problem is that the suggested fixes require changes to a WCF client configuration file - but in my case I'm using SOAP 1.1 (basicHttpBinding) with non-WCF clients.
clientCredentialType=Windows uses the built in Windows authentication which can be through Active Directory and NTLM.
Obviously the NTLM type will only use NTLM for authentication.
I'm sure you've seen it already, but here is a link to WCF security:
http://msdn2.microsoft.com/en-us/library/ms734769.aspx
Some more details on your setup would help. Are the IIS and Cassini servers running on the same box? If not do you have the same accounts setup on each box? IIS6 by default supports NTLM, so you shouldn't have a problem getting it to work.
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.