As default Config during WSO IDentity Server (WSO2 IS). we can access to admin by the https request with the port 9443 with the below link:
https://localhost:9443/carbon/
But as mentioned on the below link.we can access through Http request with port 9763. But when we access with the http request, It will redirect automatically to https.
https://docs.wso2.com/display/IS500/Default+Ports+of+WSO2+Products
I also tried to find and see a confit relating to http and https in IS_HOME/responsitory/conf/axis2.xml.
<transportReceiver name="https"
class="org.wso2.carbon.core.transports.http.HttpsTransportListener">
<parameter name="port">9443</parameter>
</transportReceiver>
<transportReceiver name="http"
class="org.wso2.carbon.core.transports.http.HttpTransportListener">
<parameter name="port">9763</parameter>
</transportReceiver>
I tried to comment a config relating to https and build again but the result is not good when I had exception here.
I want to ask how to config in WSO2 IS to use HTTP as default to access instead of HTTPS as the initial config.
I would be happy if y can support me in this case.
Thanks.
In recent versions of WSO2 IS, follow the below steps to enable HTTP access to management console.
Go to the $IS_HOME/repository/conf and open carbon.xml, and uncomment
<EnableHTTPAdminConsole>true</EnableHTTPAdminConsole>
Disable secure cookie parameter in $IS_HOME/repository/conf/tomcat/carbon/WEB-INF/web.xml file.
<session-config>
<cookie-config>
<secure>false</secure>
</cookie-config>
</session-config>
To enable HTTP access to management console Open carbon.xml located at WSO2_HOME/repository/conf directory and uncomment the following line.
<EnableHTTPAdminConsole>true</EnableHTTPAdminConsole>
Now you should be able to login. See the following.
Related
I have an ASP.NET API running locally. On the MacBook Pro, I can access the endpoints with Swagger, Postman and in the frontend (running on LiveServer) using Axios/JavaScript.
I have successfully loaded the frontend webpage on an iPhone (192.168.0.10:5500/index.html), however the Axios call to the endpoint is failing with the following error message logged to the console Failed to load resource: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “192.168.0.10”, which could put your confidential information at risk.
Running the command dotnet dev-certs https --trust generates the message Successfully trusted the existing HTTPS certificate. but does not resolve the issue.
Am I missing something?
#Lex Li's comment worked.
Steps
Remove or comment out app.UseHttpsRedirection(); in program.cs file.
In the launchSettings.json file, "applicationUrl": "https://localhost:7139;http://localhost:5171", generates a http and https url for the API endpoints. Edit the http route to the IP of the computer/local server, e.g., "applicationUrl": "https://localhost:7139;http://192.168.0.10:5171"
use the http endpoint
I have a request to allow customers to select to authenticate to our service using mTLS (Mutual Authentication). The problem I have is I want to allow this only on one endpoint and only in special circumstances. I do not want to globally accept or require Client Certificates on each request. The setting in IIS allows Ignore, Accept, or Require.
When I set it to Accept and browse to the site in Chrome I get this pop-up
Is there a way to accept the certificates if they are passed to a specific endpoint but not change the behavior of other endpoints?
To enable SSL Negotiation settings on a specific route you can apply that setting to a specific location
<location path="Route/Goes/Here">
<system.webServer>
<security>
<access sslFlags="SslNegotiateCert"/>
</security>
</system.webServer>
</location>
Depending on how your IIS is setup this may cause a 500 error saying "This configuration section cannot be used at this path. This happens when the section is locked at a parent level." If that happens you need to enable the SSL Settings Read/Write flag as seen here:
Or using Powershell:
Set-WebConfiguration //System.WebServer/Security/access[#sslFlags] -metadata overrideMode -value Allow -PSPath IIS:/
I'm migrating my application from https://mywebsite.com (1) to https://otherwebsite.com (2)
The application is host on a different servers
The code bellow work well on (1), the scheme of the generated url is https.
The same code on (2) generate an url with http scheme
$filterUrl = $this->router->generate('liip_imagine_filter', $params, UrlGeneratorInterface::ABSOLUTE_URL);
The route definition is
<route id="liip_imagine_filter" path="/media/cache/resolve/{filter}/{path}" methods="GET">
<default key="_controller">%liip_imagine.controller.filter_action%</default>
<requirement key="filter">[A-z0-9_\-]*</requirement>
<requirement key="path">.+</requirement>
</route>
Classic use of the Symfony router, have you got any ideas why on (1) I got https and on (2) I got http ?
Since you are not passing schemes and host attributes to the route liip_imagine_filter, UrlGenerator uses current request's ones.
The issue is that PHP receives request information from web server and sometimes it gets not what you expect. There might be some kind of reverse-proxy such as Nginx that accepts HTTPS requests from Internet and forward them to another Nginx by HTTP, in the end symfony receives HTTP scheme.
To find out if the (2) server behind reverse-proxy create test.php file with:
<?php
echo $_SERVER['REQUEST_SCHEME'];
It will output current request scheme.
For setting up Symfony to work under reversed proxy read this article from the official documentation: https://symfony.com/doc/current/deployment/proxies.html
I've searched the site but can't find anything that exactly matches this situation.
Cliff's Notes:
Trying to implement Federated login on GAE, using the sample python code at https://developers.google.com/appengine/docs/python/users/, with a custom OpenID Provider. GAE returns either at HTTP 500 or HTTP 204 depending on the server setup. There are no entries in the application logs on the admin console. Most likely it is a problem to do with the XRDS file and the discovery process. I'd appreciate any suggestions as to a cause or possible debugging methods. Thanks in advance.
Problem Details:
The code works fine when using the following providers in the 'federated_identity' parameter of the users.create_login_url() function:
https://www.google.com/accounts/o8/id
yahoo.com
aol.com
myopenid.com
The issues start when trying to use our own custom OpenID Provider. We have set up the OpenID plugin on a couple of Wordpress installs on different hosts for testing purposes. The plugin makes use of XRDS-Simple to publish the XRDS document at domain.com/?xrds. Example document contents:
<?xml version="1.0" encoding="UTF-8" ?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)" xmlns:simple="http://xrds-simple.net/core/1.0" xmlns:openid="http://openid.net/xmlns/1.0">
<XRD xml:id="main" version="2.0">
<Type>xri://$xrds*simple</Type>
<!-- OpenID Consumer Service -->
<Service priority="10">
<Type>http://specs.openid.net/auth/2.0/return_to</Type>
<URI>https://goff.wpengine.com/index.php/openid/consumer</URI>
</Service>
<!-- OpenID Provider Service (0) -->
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<URI>https://goff.wpengine.com/index.php/openid/server</URI>
<LocalID>http://specs.openid.net/auth/2.0/identifier_select</LocalID>
</Service>
<!-- AtomPub Service -->
<Service priority="10">
<Type>http://www.w3.org/2007/app</Type>
<MediaType>application/atomsvc+xml</MediaType>
<URI>https://goff.wpengine.com/wp-app.php/service</URI>
</Service>
</XRD>
I have verified that the OpenID provider works by using it to log in to other OpenID enabled sites, including other Wordpress installs with the OpenID plugin and Stackoverflow.
When using the login link http://api.lighthouseuk.net/_ah/login_redir?claimid=https://goff.wpengine.com/?xrds&continue=http://api.lighthouseuk.net/ GAE returns a HTTP 500 error after several seconds. We haven't found any reason for this - there are no log entries in the admin console - but I suspect it may have something to do with the configuration on wpengine.com not returning the XRDS file or caching an incorrect one.
We have semi-confirmed this by running an identical setup on our dev server which has no caching enabled. Now when we visit the login link GAE returns a HTTP 302 response followed by a HTTP 204 response: http://www.google.com/gen_204?reason=EmptyURL.
As far as I can tell, after requesting the XRDS file GAE makes no further requests to our server. This leads me to believe that there might be a problem with the XRDS file but I can't find any details in the documentation about required attributes.
Things tried:
Login on other systems
If you send an authentication request to the URI specified in the XRDS document the OpenID server responds correctly by prompting the user to log in. Again this suggests that GAE takes issues with the XRDS file because no authentication request is made to our server. I can't figure out how to debug it when there are no errors recorded in the logs.
e.g. https://goff.wpengine.com/openid/server?openid.ns=http://specs.openid.net/auth/2.0&openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select&openid.identity=http://specs.openid.net/auth/2.0/identifier_select
&openid.return_to=http://api.lighthouseuk.net/checkauth&openid.realm=http://api.lighthouseuk.net/&openid.mode=checkid_setup
SSL
Obviously for a production environment we would be using SSL on both Wordpress and GAE but currently this is just a proof of concept. cURL, by default I believe, attempts to check the validity of SSL certificates so we've tried various combinations of SSL setting, including having none at all. Seemingly no effect.
Wordpress permalinks
As the XRDS document, by default, points to /index.php/openid/server/ we attempted different combinations of permalink setting in Wordpress to see if it had any effect. It didn't.
URL encode
URL encoding the claimid seemed to have no effect - we still received the HTTP 204 response.
After giving up for a while I revisited this issue and managed to solve it. Answering here in case anyone else faces the same issues. Ultimately it was down to my use of secure URLs.
TL;DR
It should have been the first thing I checked but, make sure you have an SSL certificate on your server so that the OpenID server is accessible via a secure URL. You will get a HTTP 500 error from GAE if the URL is not secure or if the SSL certificate does not validate (Obvious in hindsight but, this caught me out on a different test site with a custom generated SSL certificate).
In addition, make sure that the XRDS document contains said secure address in the <URI> element.
Setup Details
Using OpenID plugin Version 3.3.4
Using XRDS-Simple plugin Version 1.1
Wordpress version 3.8
Hosted on WPEngine.com
Google App Engine instance running the gae-boilerplate code (federated identity enabled)
Modifications
I played around with fiddler2 to see if I could learn anything more about the requests made to and from GAE. I compared the access logs from my OpenID server on WPEngine with the data I could pull from fiddler2 about the stackexchange OpenID server (openid.stackexchange.com).
XRDS-Simple Plugin
I modified this plugin to include an additional filter for the Wordpress HTTP headers:
add_filter('wp_headers', 'xrds_add_xrds_location');
function xrds_add_xrds_location($headers) {
error_log('Adding XRDS header', 0);
$headers['X-XRDS-Location'] = get_bloginfo('url').'/?xrds';
return $headers;
}
After that I modified the xrds_write() function to simply return the following xml:
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS
xmlns:xrds="xri://$xrds"
xmlns:openid="http://openid.net/xmlns/1.0"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="10">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<Type>http://openid.net/extensions/sreg/1.1</Type>
<Type>http://axschema.org/contact/email</Type>
<URI>http://goff.wpengine.com/index.php/openid/server</URI>
</Service>
</XRD>
</xrds:XRDS>
This got rid of the http://www.google.com/gen_204?reason=EmptyURL redirect and simply returned a HTTP 500 error.
Curious, I tried various different things to get any response out of GAE (remember GAE does not show error that occur in the /_ah/ handlers.
As a last resort I modified the <URI> element to be https instead of http. This did the trick! I was successfully redirected to goff.wpengine.com and was asked to verify that I wanted to login. Excited, I clicked verify. PHP Fatal error: Call to a member function needsSigning() on a non-object. Balls. At least now I could ascertain problems from the PHP error log.
OpenID Plugin
After some quick Googling I found a thread on Google Code for the OpenID plugin. People had had similar issues and the consensus was that it was due to a plugin conflict. Comment #55 from user infinite.alis mentioned that adding the Relying Party to the user's 'Trusted Sites' consistently solved the problem. Lo and behold, after adding the address to my trusted sites the entire authentication flow completed without error!
Conclusion
I have yet to do a post mortem to figure out which of the changes to XRDS-Simple made the difference. I suspect that simply changing the <URI> element in XRDS-Simple to https would solve the problem (My previous tests with SSL only focused on making sure the users.create_login_url() function was passed a secure address, not that the XRDS file described the OpenID server via a secure address). Possibly need to play around with the filters for get_bloginfo('url') in the xrds_write() function.
I am trying to create an example that uses HTTPS connection. I have successfully configured a custom certificate following the steps given in Tomcat 6.0 documentation. A https://localhost:8443/ successfully opens the Tomcat index page.
I am unable to configure a page/servlet to open in HTTPS. Would anyone please suggest me the steps to configure a webapp to automatically redirect itself into a HTTPS connection.
Requests using HTTP (non-secure) for URLs whose transport guarantee is CONFIDENTIAL are automatically redirected to the same URL using HTTPS.
Add the following to your web.xml
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>