I can log into the Portal using its host name, but not url. Why?
Example:
https://developer.think.ibm/ works
https://192.168.225.20/ returns a 403 and 'nginx'
My 'on-premises' cloud consists of 4 vms that were provided in a workshop in IBM South Bank in June 2016. I am in the process of refreshing my APIC skills and extending them. Rather than use the Ubuntu vm where the Toolkit is installed, I have been using it in Windows 10, and accessing the APIM and CMC from Firefox and Chrome in Windows, using the ip address of the vm.
I have come to the conclusion that there must be a config value in the CMC or Portal, that forces Portal to only accepts urls containing 'developer.think.ibm'. Using the ip-address, also fails from Firefox in Ubuntu. In Windows, I added 'developer.think.ibm' to my hosts file and now I can access the Portal. Using vmware's NAT port forwarding 'localhost:4443', returns a 404.
It seems to me that inital access to the Portal, by its nature, should be easy, as this is the whole point of having an API manager.
Regards, John
Your Portal Server hosts multiple Portal sites (each Catalog has its own Portal site). The IP address of the server doesn't identify a site so you need to use the site's url (which is configured as part of the catalog configuration in API Manager). URLs for different sites may have different virtual hosts, or differ only in their paths.
Related
I am new to Cloud Foundry.
Is there any way that only specific users can view and update an app deployed in Cloud Foundry?
1.I deployed an app in Cloud Foundry using “cf push”command.
2.After entering “cf push “command I’ve got an message below.
Using manifest file /home/stevemar/node-hello-world/manifest.yml
enter Creating app node-hello-world-example...
name: node-hello-world-example
requested state: started
routes: {route-information}
last uploaded: Mon 14 Sep 13:46:54 UTC 2020
stack: cflinuxfs3
buildpacks: sdk-for-nodejs
type: web
instances: 1/1
memory usage: 256M
3.Using the {route-information} above,I can see the app deployed via browser entering below URL.
https://{route-information}
By this way ,anyone can see app from browser, but I don’t want that to be seen by everyone and limit access to specific user.
I heard that this global IP will be allocated to {route-information} by default.
Is there any way to limit access to only between specific users?
(For example,is there any function like “private registry” at Kubernetes in Cloud Foundry which is not open to public)
Since I am using Cloud Foundry in IBM Cloud it would be better if there is solution using IBM Cloud.
I’ve already granted cloud foundry role to the other user.
Thank you.
The CloudFoundry platform itself does not provide any access controls for applications. If you assign a public route to your application, where the DNS is publicly resolvable and the foundation is on the public Internet, like IBM Bluemix, then anyone can access your app.
There's a number of things you can do to limit access, but they do require some work on your part.
Use a private DNS. You can add any domain you want to Cloud Foundry, even ones that don't resolve. That means you could add my-cool-domain.local which does not resolve anywhere. You could then add a record to /etc/hosts for this domain or perhaps run DNS on your local network to resolve this DNS domain and direct traffic to the CloudFoundry.
With this setup, most people cannot access your application because the DNS domain for the route to your application does not resolve anywhere. It's important to understand that this isn't really security, but obscurity. It would stop most traffic from making it to your app, but if someone knew the domain, they could add their own /etc/hosts header or send fake Host headers to access your application.
This type of setup can work well if you have light security requirements like you just want to hide something while you work on it, or it can work well paired with other options below.
You can set up access controls in your application. Many application servers & frameworks can do things like restrict access by IP address or require user access (Basic auth is easy and it is OK, if you're only allowing HTTPS traffic to your app which you should always do anyway).
You can use OAuth2 to secure apps too. Again, many app servers & frameworks have support for this and make it relatively simple to secure your apps. If you don't have a corporate OAuth2 solution, there are public providers you can use. Exactly how you do OAuth2 in your app is beyond the scope of this question, but there's plenty of material out there on how to do this. Google information for your application language/framework of choice.
You could set up an access Gateway. This would be an application that's job is to proxy traffic to other applications on the foundation. The Gateway could be something like Nginx, Apache HTTPD, or Spring Cloud Gateway. The idea is that the gateway would be publicly accessible, and would almost certainly apply access controls/restrictions (see #2, many of these proxies have access control options that only take a few lines of config). Your actual applications would not be deployed publicly though. When you deploy your actual applications, they would only be on the internal Cloud Foundry domain.
CloudFoundry has local domains, often apps.internal (run cf domains to see if that shows up), which you can use to easily route traffic across the internal container-to-container network. Using this domain and the C2C network, you can have apps deployed to CF that are not accessible to the public Internet, except through your Gateway.
Again, how you configure this exactly is outside the scope of this question, but check out the docs I linked to for info on using the C2C network & internal routes. Then check out your proxy server of choice's documentation.
I have two servers , Server #1 one hosted in the office using the office network (this hosts the tableau server on ubuntu server) and the other server Server #2 sitting in another collocated network. The web application is hosted in server #2 and the tableau dashboards are embended on the web application.
When I try to access the application from another public network , the dashboards are working very well, however when I try to access the dashboards from the office network (which hosts the tablueau server ), I get the following error =>
That error is generally caused by one of two issues
The IP Address of Webserver hosting the IFrame was not whitelisted under Trusted Authentication in TSM or Add Trusted IP Addresses or Host Names to Tableau Server
or
The trusted user does not exist on the Tableau server and/or the username does not match what was passed to the webserver from your web application hosting the Iframe.
We have trusted_ticket_expiry set to 240 minutes.
https://kb.tableau.com/articles/issue/changing-the-expiration-timeout-of-trusted-tickets
We host a website in our company.
A certificate was issued to www.ourdomainname.com from the company IT department.
Now we want to move the website to azure and install the certificate there.
I already exported the certificate with private key exported set to true from the server.
1.) What will happen when the certificate is installed on azure when it is also installed on our company server?
2.) What will happen when the website on our server is stopped in the server and the certificate is then imported to the azure website?
3.) How can I guarantee a soft transition time without any break?
The aim is:
Website on the company server going to be deleted and the website on azure is used instead.
What will happen when the certificate is installed on azure when it is also installed on our company server?
web site will be available via SSL in Azure too.
What will happen when the website on our server is stopped in the server and the certificate is then imported to the azure website?
web site on your server will be inaccessble.
How can I guarantee a soft transition time without any break?
it is more about DNS management. There is no much work with SSL. You just install SSL on both internal and Azure servers, so clients can access both. Test if web site on Azure works the same way as on your internal server. Then point all clients (via DNS) to a web site on Azure. When all clients move and there are no references to internal server, you can safely shutdown it.
The SSL Certificate which was exported from the current server has to be imported in Azure. The format of the certificate has to be PFX.
Now, in the DNS Management , you need to edit the A record for the URL and point it to the IP address of Azure. This will make sure that any request made will be handled by Azure .
I have a self-hosted owin web api service on a test environment, and to give it a better name I use a domain alias, and ARR.
My web api runs on port 8888, and uses Windows Authentication. I have configured my arr to run under testserver:80 with anonymous authentication. I want to deploy a service on the box that will pool the webapi for data. When I try to visit testserver from my web browser on my desktop it works fine. However, when I remote into that box and try to hit testserver it prompts me for credentials. Even if I type them correctly it still will issue me a 401. If I go to localhost:8888 the site will work.
Since, I'd prefer to use the pretty name for the server in my service how do I correct this issue. How do I get it to pass credentials on the same box through ARR?
You might have have an issue with LSA loopback checking.
You get the 401 because ARR forwards your Windows Authentication to localhost, which is not allowed (default setting).
Try to disable LSA loopback checking (restart most probably required). If that works you can limit the disabling of loopback checking to specific websites (to prevent security holes).
See You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version for more information on the LSA loopback check and how to disable it completely or only for specific hostnames.
I am trying to send email using one of our on-premises servers from one of my web roles hosted on azure. We've got a Windows Azure Connect endpoint installed on this on-premises server which has an SMTP server.
We've configured the web role so that it contains an activation code I acquired using the windows azure portal and the azure subscription we have. The web role has been deployed to azure with this configuration. Looking in the virtual network section of the portal I can see our on-premises server listed as well as the instance of said web role. I Created a group connecting the local endpoint to the web role instance.
The problem I'm having now is figuring out exactly what I have to do in order for the emails I send from the web role to be relayed through the smtp server on the on-premises server.
My first thought was to just specify the local endpoint name as it appears in our azure portal as the host to use when I create my SmtpClient object in code. Of course this didn't work as I received an SmtpException just saying Failure Sending Email.
So my question is once I've set everything up as described above, what do I need to do in ,my web role code and/or configuration in order to use the local endpoint as the smtp host for sending out my emails??
How about open your firewall for the SMTP on both your azure VM and local server.
As I know the azure VM firewall disabled the PING (ICMP) but doesn't know if it blocked all ports except those defined in your CSDEF file.