Has anyone deployed the CRM 2011 PRM portal and had it working over https?
The ServiceContext.GetUrl(page) method seems to return the correct URL, but with port 80 post-fixed:
i.e. https://example.com:80/cases/editCase?CaseID=52560671-2fdb-e011-9599-00505682001c
Trying to figure out a way to track down if this is due to IIS configuration or the ServiceContext library that is doing this.
Can you double-check that the port 80 is in fact a result of calling GetUrl or is it the result of being passed through a UrlBuilder object. If the UrlBuilder is at fault you can call the PathWithQueryString property to omit the host and port values.
var url = new UrlBuilder(ServiceContext.GetUrl(page));
url.QueryString.Set("CaseID", id.ToString());
var path = url.PathWithQueryString;
If you need to keep the port value, it can be updated manually.
url.Port = Request.Url.Port;
This should not be an issue with your IIS configuration.
Related
I need to make calls to a rest API service via BizTalk Send adapter. The API simply uses a token in the header for authentication/authorization. I have tested this in a C# console app using httpclient and it works fine:
string apiUrl = "https://api.site.com/endpoint/<method>?";
string dateFormat = "dateFormat = 2017-05-01T00:00:00";
using (var client = new HttpClient())
{
client.DefaultRequestHeaders.Add("token", "<token>");
client.DefaultRequestHeaders.Add("Accept", "application/json");
string finalurl = apiUrl + dateFormat;
HttpResponseMessage resp = await client.GetAsync(finalurl);
if (resp.IsSuccessStatusCode)
{
string result = await resp.Content.ReadAsStringAsync();
var rootresult = JsonConvert.DeserializeObject<jobList>(result);
return rootresult;
}
else
{
return null;
}
}
however I want to use BizTalk to make the call and handle the response.
I have tried using the wcf-http adapter, selecting 'Transport' for security (it is an https site so security is required(?)) with no credential type specified and placed the header with the token in the 'messages' tab of the adapter configuration. This fails though with the exception: System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
I have tried googling for this specific scenario and cannot find a solution. I did find this article with suggestions for OAUth handling but I'm surprised that even with BizTalk 2016 I still have to create a custom assembly for something so simple.
Does anyone know how this might be done in the wcf-http send adapter?
Yes, you have to write a custom Endpoint Behaviour and add it to the send port. In fact with the WCF-WebHttp adapter even Basic Auth doesn't work so I'm currently writing an Endpoint Behaviour to address this.
One of the issues with OAuth, is that there isn't one standard that everyone follows, so far I've had to write 2 different OAuth behaviours as they have implemented things differently. One using a secret and time stamp hashed to has to get a token, and the other using Basic Auth to get a token. Also one of them you could get multiple tokens using the same creds, whereas the other would expire the old token straight away.
Another thing I've had to write a custom behaviour for is which version of TLS the end points expects as by default BizTalk 2013 R2 tries TLS 1.0, and then will fail if the web site does not allow it.
You can feedback to Microsoft that you wish to have this feature by voting on Add support for OAuth 2.0 / OpenID Connect authentication
Maybe someone will open source their solution. See Announcement: BizTalk Server embrace open source!
Figured it out. I should have used the 'Certificate' for client credential type.
I just had to:
Add token in the Outbound HTTP Headers box in the Messages tab and select 'Transport' security and 'Certificate' for Transport client credential type.
Downloaded the certificate from the API's website via the browser (manually) and installed it on the local servers certificate store.
I then selected that certificate and thumbprint in the corresponding fields in the adapter via the 'browse' buttons (had to scroll through the available certificates and select the API/website certificate I was trying to connect to).
I discovered this on accident when I had Fiddler running and set the adapter proxy setting to the local Fiddler address (http://localhost:8888). I realized that since Fiddler negotiates the TLS connection/certificate (I enabled tls1.2 in fiddler) to the remote server, messages were able to get through but not directly between the adapter and the remote API server (when Fiddler WASN'T running).
I am using Visual Studio 2015 Enterprise and ASP.NET vNext Beta8 to build an endpoint that both issues and consumes JWT tokens as described in detail here. As explained in that article the endpoint uses AspNet.Security.OpenIdConnect.Server (AKA OIDC) to do the heavy lifting.
While standing this prototype up in our internal development environment we have encountered a problem using it with a load balancer. In particular, we think it has to do with the "Authority" setting on app.UseJwtBearerAuthentication and our peculiar mix of http/https. With our load balanced environment, any attempt to call a REST method using the token yields this exception:
WebException: The remote name could not be resolved: 'devapi.contoso.com.well-known'
HttpRequestException: An error occurred while sending the request.
IOException: IDX10804: Unable to retrieve document from: 'https://devapi.contoso.com.well-known/openid-configuration'.
Consider the following steps to reproduce (this is for prototyping and should not be considered production worthy):
We created a beta8 prototype using OIDC as described here.
We deployed the project to 2 identically configured IIS 8.5 servers running on Server 2012 R2. The IIS servers host a beta8 site called "API" with bindings to port 80 and 443 for the host name "devapi.contoso.com" (sanitized for purposes of this post) on all available IP addresses.
Both IIS servers have a host entry that point to themselves:
127.0.0.1 devapi.contoso.com
Our network admin has bound a * certificate (*.contoso.com) with our Kemp load balancer and configured the DNS entry for https://devapi.contoso.com to resolve to the load balancer.
Now this is important, the load balancer has also been configured to proxy https traffic to the IIS servers using http (not, repeat, not on https). It has been explained to me that this is standard operating procedure for our company because they only have to install the certificate in one place. We're not sure why our network admin bound 443 in IIS since it, in theory, never receives any traffic on this port.
We make a secure post via https to https://devapi.contoso.com/authorize/v1 to fetch a token, which works fine (the details of how to make this post are here ):
{
"sub": "todo",
"iss": "https://devapi.contoso.com/",
"aud": "https://devapi.contoso.com/",
"exp": 1446158373,
"nbf": 1446154773
}
We then use this token in another secure get via https to https://devapi.contoso.com/values/v1/5.
OpenIdConnect.OpenIdConnectConfigurationRetriever throws the exception:
WebException: The remote name could not be resolved: 'devapi.contoso.com.well-known'
HttpRequestException: An error occurred while sending the request.
IOException: IDX10804: Unable to retrieve document from: 'https://devapi.contoso.com.well-known/openid-configuration'.
We think this is happening because OIDC is attempting to consult the host specified in "options.Authority", which we set at startup time to https://devapi.contoso.com/. Further we speculate that because our environment has been configured to translate https traffic to non https traffic between the load balancer and IIS something is going wrong when the framework tries to resolve https://devapi.contoso.com/. We have tried many configuration changes including even pointing the authority to non-secure http://devapi.contoso.com to no avail.
Any assistance in helping us understand this problem would be greatly appreciated.
#Pinpoint was right. This exception was caused by the OIDC configuration code path that allows IdentityModel to initiate non-HTTPS calls. In particular the code sample we were using was sensitive to missing trailing slash in the authority URI. Here is a code fragment that uses the Uri class to combine paths in a reliable way, regardless of whether the Authority URI has a trailing slash:
public void Configure(IApplicationBuilder app, IOptions<AppSettings> appSettings)
{
.
.
.
// Add a new middleware validating access tokens issued by the OIDC server.
app.UseJwtBearerAuthentication
(
options =>
{
options.AuthenticationScheme = JwtBearerDefaults.AuthenticationScheme ;
options.AutomaticAuthentication = false ;
options.Authority = new Uri(appSettings.Value.AuthAuthority).ToString() ;
options.Audience = new Uri(appSettings.Value.AuthAuthority).ToString() ;
// Allow IdentityModel to use HTTP
options.ConfigurationManager =
new ConfigurationManager<OpenIdConnectConfiguration>
(
metadataAddress : new Uri(new Uri(options.Authority), ".well-known/openid-configuration").ToString(),
configRetriever : new OpenIdConnectConfigurationRetriever() ,
docRetriever : new HttpDocumentRetriever { RequireHttps = false }
);
}
);
.
.
.
}
In this example we're pulling in the Authority URI from config.json via "appSettings.Value.AuthAuthority" and then sanitizing/combining it using the Uri class.
I have a desktop application that is self hosting a NancyFX web server. Being a desktop application there is a requirement that we allow dynamic IP addresses so we have registered the url using the wildcard option with netsh, as so:
netsh http add urlacl url=http://+:1234/ user=Everyone
However when this application is run under a non-administrator account the following exception is thrown.
The Nancy self host was unable to start, as no namespace reservation existed for the provided url(s).
Please either enable UrlReservations.CreateAutomatically on the HostConfiguration provided to
the NancyHost, or create the reservations manually with the (elevated) command(s):
netsh http add urlacl url=http://192.168.1.90:1234/ user=Everyone
I have tried many combinations of wildcard registrations, all with the same result. I also looked at registering the wildcard when loading Nancy, but due to Nancy using Uri types this was not valid.
I was under the assumption that by using the wildcard registration I had registered any ip address to be used. But Nancy seems to need the specific ip address registered.
I would really appreciate if someone could tell my why the wildcard registration will not work with Nancy, or even better, how to make it work with Nancy.
An old question but if anyone runs into this, Nancy SelfHost allows you to create Url reservations automatically using the HostConfiguration object.
The Url is then reserved automatically on startup.
//Nancy configuration
HostConfiguration hostConfig = new HostConfiguration()
{
UrlReservations = new UrlReservations()
{
//create URL reservations automatically
CreateAutomatically = true
}
};
//Uri
Uri uri = new Uri("http://localhost:9999");
using (var host = new NancyHost(hostConfig, uri))
{
host.Start();
Console.WriteLine("Running self-hosted server ...");
Console.WriteLine("Press [Enter] to close the application.");
Console.ReadLine();
}
I have a Classic ASP page that made an LDAP call to our Domain Controllers to find out the group membership of the logged on user. Since our Network Admin demoted the two old Windows Server 2003 Domain Controllers and promoted two Windows Server 2008 R2 servers the page now fails at Set CurrentUser = GetObject("LDAP://" & ADSysInfo.UserName) (see code) with the error 800704bc.
Dim Strgroups
Const STAFF_GROUP = "cn=staff"
Const STUDENT_GROUP = "cn=student"
Set ADSysInfo = CreateObject("ADSystemInfo")
Set CurrentUser = GetObject("LDAP://" & ADSysInfo.UserName)
If IsArray(CurrentUser.MemberOf) Then
strGroups = LCase(Join(CurrentUser.MemberOf))
Else
strGroups = LCase(CurrentUser.MemberOf)
End If
Any help is appreciated. Thanks in advance.
I'm guessing it's not the code that's the problem, but rather a something to do with the new servers (obviously).
I don't know what error 800704bc is, but check and see that ADSysInfo is actually getting instantiated. If not, then maybe there's a module missing on the server or something.
Not sure why but I needed to open the high ports (1024+) on the firewall between the server and the DCs. Must be an RPC thing.
Do the new servers block unencrypted binds? If so, then this would make sense as you bind as LDAP not LDAPS nor StartTLS.
I am writing code in asp.net to get XML data from external webserver.
*.cs Code
connection string: URL of external(third party) server for XML data
WebRequest req = WebRequest.Create(connectionString);
req.Proxy = WebProxy.GetDefaultProxy();
req.Proxy.Credentials = CredentialCache.DefaultCredentials;
req.Timeout = 1000;
using (WebResponse resp = req.GetResponse())
{
// reading data from XML file
}
Key Point
1. GetDefaultProxy() return information about proxy
2. Default Credentials() return username password which i have written in web.config as shown below
Web.config
<identity impersonate="true"
username="Username of PC where website is running"
password="password"/>
Problem Statement:
After installing website setup : Above code working fine at WindowsXP but the same code doesn't work at Windows server 2003. I am not able to find out what extra we need to configure in Windows Server 2003.
Please help me to find out the solution?
[EDIT]
Very random beheviour is observed at server. Sometimes the data comes and appear at client(browser) when we logged into windows server 2003.
But when we loggedout from server and try to request for data from client(browser) at another PC. It appear for very short duration. After say wait of 1 hour the data doesn't comes for new request.
An error message might be useful??
But at a guess I'd say it's that the proxy isn't configured on the 2003 server.
Check the firewall on Windows Server 2003 and make sure port 80 outbound is allowed (assuming that is the port used by the web service).
This might help. It's about proxy and .NET app.