Storage account - The account being accessed does not support http - asp.net-mvc

I have created an MVC Web application application and a storage account(Table). I'm getting the error
StatusMessage:The account being accessed does not support http.
ErrorCode:AccountRequiresHttps
When I created an MVC application, I have ticked Configure for Https. Would anyone know where I can configure it to use https and why I'm not able to access it? (I tried running on both IIS express and IIS)
Thanks in advance

Explanation
By default, an Azure Storage account requires secure access (that means access over HTTPS) by default.
The box you checked (Configure for HTTPS) means that the MVC Web Application is accessible via HTTPS (only). The error you're getting is that you are accessing the Storage Account over HTTP. So that's an outgoing connection to your storage account from your web application. This is not covered by the box you checked.
Solution
If you want to connect to the Storage Account using HTTPS, make sure the connection string you are using for the storage account contains/starts with DefaultEndpointsProtocol=https;. This configures the storage account client to access the storage account over HTTPS.
Additional info
The secure transfer option enhances the security of your storage account by only allowing requests to the storage account by secure connection. For example, when calling REST APIs to access your storage accounts, you must connect using HTTPs. Any requests using HTTP will be rejected when 'secure transfer required' is enabled.
EDIT:
If you're using the constructor for the CloudStorageAccount class to 'build' the connectionstring, make sure to pass in true for the useHttps parameter.

Related

Auth0 ADFS - Can't Find Federation Metadata URL - Next Steps

This post became much longer than anticipated, TLDR: Where is my ASFS Federation Metadata located on my server? My overall task to the setup a test ADFS server in order to integrate our current application with ADFS
Hello, I'm trying to integrate our application with ADFS (it's a WPF application with a NodeJS backend), and I'm testing out Auth0 for this job (but if there are other simple solutions, I would be open to that as well - I've found no good guides so far ): espeically as a developer with no AD experience).
Regardless, I think I've set up a single server AD FS environment (locally as server1.local - with AD CS, AD DS and AD FS and that same server is the domain controller/DNS server) and set up an Auth0 relying party using this guide:
https://auth0.com/docs/connections/enterprise/adfs
In the next steps part, it says: try these quickstart guides. So I've downloaded the Angular2 quick start example project to test. But when I go to the enterprise connections and try to set up an ADFS connection, it asks for a ADFS URL
You can either provide the ADFS URL or upload the federation metadata file.
But I can't seem to find my ADFS URL. Not only that, my server is local, so it wouldn't be able to use my URL anyways right? I can just upload the metadata instead?
I've tried going to https://server1.local/federationmetadata/2007-06/federationmetadata.xml and https://127.0.0.1/FederationMetadata/2007-06/FederationMetadata.xml and https://localhost/FederationMetadata/2007-06/FederationMetadata.xml which under endpoints that's the one that shows, but ie says:
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://server1.local again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.
I've enabled TLS 1.0, 1.1 and 1.2 and this still doesn't seem to give me my metadata. I've also tried that URL on Chrome and it gives a generic "This site can't be reached"
How do I get my metadata?
In the ADFS configuration, look for what you configured as your federation service name.
Use this in the URL.
https://federation service name/federationmetadata/2007-06/federationmetadata.xml
BTW the federation service name should not be the FQDN of the server.

Privacy of Hyperledger composer rest server

In Hyperledger composer rest api (composer-rest-server) are secure with Enabling authentication for the REST server. but in http://localhost:3000/explorer, All sensitive data is not encryption. Could i use cryptography or other approach to encrypt and decrypt like Zero Knowledge Proof to prevent data privacy (sensitive data)?
And I see Securing the REST server using HTTPS and TLS, when i run command composer-rest-server -c alice1#my-network -t and then open browser https://localhost:3000/explorer, but I don't know how to use it?
Thank you in advance!
Firstly, you would use TLS between the REST client and REST server - see https://hyperledger.github.io/composer/latest/integrating/securing-the-rest-server and general/useful info on TLS with diagrams here
You would really need to set up authentication (known user identities that are using it) with TLS like discussed here then connect to the authentication path for your application to authenticate the user using the REST APIs https://localhost:3000/auth/github: ((or whatever the authPath is for your implemented strategy)) and then interactions/ data in transit between client and server will be encrypted.
Once the REST server is up and running and TLS enabled - you will authenticate at your REST client as the user in question: once authenticated, that user gets an access token or similar. In terms of Composer and the deployed business network / smart contract - that user will (already) have been issued a business network card - that includes the user's blockchain identity (key/cert) and contain connection info/metadata (ie how to connect to the deployed/runtime business network out on the Fabric network). This access may be programmatically, from an application client that's using REST APIs (ie the app user that's logged in to the app, has been assigned this business network card) or indeed - a user is using the REST API client in a browser for example (eg. he/she would import it into their Wallet in the REST client then that would be the default identity in the REST API session, and which interacts / signs transactions that update the business network (create asset, update asset etc), as REST API operations to the REST Server (over TLS) that interacts with the Fabric network (over TLS).

Getting client certificates in Azure Web App using OWIN

If you are using Azure Web Apps to host your web application (let it be an ASP.NET MVC web app) you do not have the possibility to set up the IIS behind the Azure Web App to accept client certificates through an HTTPS connection. My application has some Web API endpoints that would be only accessible if the user has the correct certificate with the allowed thumbprint. However, I have other endpoints as well (and of course the website) that would be accessible without a client certificate. So in my case the only way is to accept client certificates.
I am not sure about that, but if I know well I can still get the client certificate by using OWIN while the SSL Settings in IIS is set to Ignore. If I use OWIN and go through the OWIN environment I can see a key called ssl.LoadClientCertAsync.
I am implementing endpoints that a third-party service will call, so I have no control over the content of the request. I know that there is a ssl.ClientCertificate key, with type X509Certificate, but in my case this key doesn't exist.
I have found some C# solution about using this ssl.LoadClientCertAsync key to get the certificate like in the CheckClientCertificate method of Katana or the solution in this C# Corner article. In every solution that I can find in the net, the author gets this type as a Func<Task> and then calls this task, by for example using the await operator.
var certLoader = context.Get<Func<Task>>("ssl.LoadClientCertAsync");
if (certLoader != null)
{
await certLoader();
...
After that they retrieves the certificate by using the ssl.ClientCertificate key.
var asyncCert = context.Get<X509Certificate>("ssl.ClientCertificate");
In this example, my asyncCert variable is always null. There weren't any ssl.ClientCertificate key in the OWIN context. I have tried to use the X509Certificate2 instead of X509Certificate, but I still got null.
My question is is it possible to get the client certificate in an Azure Web Site while the default SSL setting is Ignore by using OWIN? If yes, why can't I get the certificate using the ssl.LoadClientCertAsync key?
According to your description, I have created my ASP.NET MVC web application for working with client certificate in OWIN to check this issue. The following code could work on my local side:
if (Request.GetOwinContext().Environment.Keys.Contains(_owinClientCertKey))
{
X509Certificate2 clientCert = Request.GetOwinContext().Get<X509Certificate2>(_owinClientCertKey);
return Json(new { Thumbprint = clientCert.Thumbprint, Issuer = clientCert.Issuer }, JsonRequestBehavior.AllowGet);
}
else
return Content("There's no client certificate attached to the request.");
For SSL Settings set to Accept, I could select a certificate or cancel the popup window for selecting a certificate.
AFAIK, we could enable the client certificate authentication by setting clientCertEnabled to true and this setting is equivalent to SSL Settings Require option in IIS.
As How To Configure TLS Mutual Authentication for Web App states about accessing the Client Certificate From Your Web App:
If you are using ASP.NET and configure your app to use client certificate authentication, the certificate will be available through the HttpRequest.ClientCertificate property. For other application stacks, the client cert will be available in your app through a base64 encoded value in the X-ARR-ClientCert request header.
My question is is it possible to get the client certificate in an Azure Web Site while the default SSL setting is Ignore by using OWIN?
AFAIK, the current SSL Settings for client certificates only supports Ignore and Require for now. When hosting your web application on azure web app, for the client users who access your azure web app with client certificate authentication, they could specify the certificate to a base64 encoded value as your custom request header when sending request to your azure web app, then your could try to retrieve the header and verify the cert if the cert custom request header exists. Details, you could follow this sample.
Additionally, you could use Azure VM or Azure Cloud Service instead of azure web app, at this point you could fully control the SSL Settings in IIS.

WebSphere Liberty Profile OIDC Client URL

I am trying to use the WebSphere Liberty Profile OIDC Client feature. I have the feature installed and configured, but I am confused about what URL I should be using to connect to it. In the WLP Knowledge Center, it shows an example like this:
https://server.example.com:443/oidc/endpoint/PROVIDER_NAME/authorize
But when my WLP server comes up, I see the following URL in the log:
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost I addWebApplication SRVE0250I: Web Module OpenID Connect Client Redirect Servlet has been bound to default_host.
com.ibm.ws.http.internal.VirtualHostImpl A CWWKT0016I: Web application available (default_host): http://ibm669-r9v0dvb:11080/oidcclient/
I don't know whether to use 'oidcclient' (probably) or 'oidc'. I also don't know what to put as the PROVIDER_NAME. I tried using the ID of my OIDCClient:
<openidConnectClient id="oidcRP"
clientId="${oauth.client.id}"
clientSecret="${oauth.client.secret}"
authorizationEndpointUrl="${oauth.authorize.endpoint}"
tokenEndpointUrl="${oauth.token.endpoint}"
httpsRequired="false"
redirectToRPHostAndPort="https://myhost.com:443">
I tried connecting with this, but it's not finding it:
http://ibm669-r9v0dvb:11080/oidcclient/endpoint/oidcRP/authorize?scope=openid&response_type=code&client_id=XXX&redirect_uri=https://myhost.com:443
com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor W handleRequest SRVE0190E: File not found: /endpoint/oidcRP/authorize
Can anyone tell me what URL I should be using to connect to the client?
The Liberty openidConnectClient feature enables Liberty as a client to openid connect provider. The configuration parameters inside openidConnectClient are information about openidConnectProvider, for example, the openidConnect provider's authorization endpoint and token endpoint.
What is your openid connect provider? Liberty also can be configured as openid Connect provider. If you also want to use Liberty as openid connect provider, you can create another Liberty instance and enable openidConnectProvider feature.

can I securely access Gmail for a Rails app on shared hosting non-SSL without putting credentials at risk?

That is, want a Rails application that lets me see a customized view of the user's Gmail calendar. But it'll be on shared hosting so don't want to store credentials, or have them in the clear.
Question: Can I securely access Gmail for a Rails app on shared hosting non-SSL without putting credentials at risk? How would I do this? (e.g. does OAuth or OpenID solve this)
Requirements would be:
Rails application will call Google Calendar via API
No credentials stored on shared hosting site (e.g. in database or whatever) - MANDATORY
Rails site is non-SSL - MANDATORY (for the purpose of this question)
Ability to stay logged in whilst browser still open - DESIREABLE (assume using session id...assuming this is secure)
For example exiting approach I've used which wouldn't satisfy my requirements on my non-SSL rails site (on a shared host) would be:
# Get Google Calendar
service = GCal4Ruby::Service.new
service.authenticate("<google account name>", "<password>") # <== requires password
cal = GCal4Ruby::Calendar.find(service, "myCalendar")[0]
# Get Google Events
search_str = "<search str>"
#events = GCal4Ruby::Event.find(cal, search_str, params)
You will get mixed content if you try to include in an http page an https Google calendar view loaded as an iframe.
If you're just doing API calls, as long as the API calls are from your server to an encrypted endpoint, https://calendar.google.com or something similar, then there are no problems.
If you're doing API calls from a non-http page in the browser, then a determined attacker will be able to eavesdrop on any data you serve, including credentials sent to the browser for forwarding to the calendar service.
If you're sending credentials to the browser you should also worry about exfiltration via XSS.

Resources