WSO2 identity server login page is empty - wso2-identity-server

I am new to WSO2 identity server and going through their documentation for samples. But after running the server when i hit the browser with below url
https://localhost:9443/carbon/admin/login.jsp
i am getting empty page only (I have added the https security exception as well).
Do i need to do anything additionally ? for the admin user (admin/admin)

I found the solution. We need to setup only the tested jdks that are mentioned in their page. But it should also support later versions too. Looks crazy some time. I have used the latest jdk 8.161 for wso2 is 5.0.

Run WSO2 from command line and check out the logs for end points or wso2 services Port already in use: xxxx error before java.net.BindException: Address already in use (Bind failed) which may caused by other startup process and kill them.
On linux will be:
sudo kill -9 `sudo lsof -t -i:xxxx`
(where the xxxx is the port number)

Related

Customizing the API Manager URL(s) - Windows

So i'm trying to change the default URL for WSO2 features i.e. Publisher, Carbon, Store from localhost to, lets say, myDomain.com.
I've looked for it in the WSO2 documentation but i keep finding this article over and over again
https://docs.wso2.com/display/AM210/Customize+the+API+Store+and+Gateway+URLs
The problem with this is that it has linux-based (i suppose) commands listed that cannot be applied to windows.
I've also tried to change the host < HostName > and < MGT HostName > tags in the carbon.xml of the WSO2 product but it does not respond and display the page AT ALL! just works with the localhost. thats it
Any ideas or options for the windows end? Thanks
1) Yes, the commands given in the doc are for linux. But what those commands do is installing nginx. So you can ignore those commands, and install nginx in windows.
NGinx configurations given in the doc will be the same for any OS.
2) If you add a hostname to <HostName> and <MGT HostName> tags, you need to have IP to hostname mapping somewhere. I think there is a host file in windows for that.

change port in wso2 sample

I am executing sample programm of wso2. I have installed wso2is on different machine and tomcat is on local machine. I have changed localhost:9443 to my ipaddress(eg 192.168.1.xxx) from travelocity.properties and avi.properties. But when I execute sample from click on login button it always redirecting me localhost and giving error.
I think you need to try the following,
While the tomcat is running,
Open the travelocity.war with an archive manager
Edit the travelocity.properties file,
update SAML2.IdPURL value
eg : SAML2.IdPURL=https://192.168.1.7:9443/samlsso
Save and update the travelocity.com web app
Restart the tomcat server just to be sure (You don't really have to do this since tomcat hot deploys once it detects a change)
I tried this locally and it redirected me to the IP address I put in SAML2.IdpURL. Clearly the problem seems to be a configuration error on the travelocity.com web app side :)
You need to change <HostName> and <MgtHostName> attributes at repository/conf/carbon.xml of your Identity Server with your IP address. By default they are set as localhost, so when logging it will be redirected to location specified there.

How can i allow people in my local network to access the web service in my machine?

I have coded a web service using the Axis 2 framework and I can successfully invoke it using a test client (SoapUI) on the local machine after publishing the application in JBoss 5. I can post to the WS endpoint from the local machine and get the expected response.
Now i want to allow other machines to access the web service.
i changed the "localhost" to "my own fixed IP" adress at the end point location, and turned firewall off, but impossible to access the WS.
Note : windows Xp SP3.
Any idea ?
Thanks in advance !!
Please ensure you follow below steps
For example, if your ip is 10.132.243.54
List item
Checking if your IP is pingable by other systems
Instead of running with eclipse, run your jboss from your
command-prompt
start jboss-server suffixing -b in run.bat. The command is run.bat
-b 10.132.243.54
Access the WS from SOAP-UI using IP and not using localhost
If your IP is still not pingable, turn off the firewall, after
following above steps
Sorry for the late reply, However this would solve the problem i guess

No Established Sessions corresponding to Session Indexes

I am testing wso2stratos-is-1.5.2 in a stand alone mode. I unzip the product. I enter the bin directory and run ./wso2server.sh , i login as admin, I try to logout and I get the following error message in the log file
Stratos Identity]ERROR
{org.wso2.carbon.identity.sso.saml.processors.LogoutRequestProcessor}
- No Established Sessions corresponding to Session Indexes provided. {org.wso2.carbon.identity.sso.saml.processors.LogoutRequestProcessor}
I wonder if some one of greater knowledge could inform me why this happens out of the box?
What i ended up doing to fix this problem is like I said in my comment.
I copied the repository/conf/advanced directory from the working full stratos install IS Server and pasted it into the stand-alone version of Stratos IS. And made sure the port number in authenticators.xml was pointing to the stand-alone port number.
Then I copied the following files from the working Stratos IS Server and pasted into the Stand-alone version, modifying the port numbers to be relevant to the stand-alone
1. sso-idp-config.xml
2. Identity.xml
3. Carbon.xml
Now I can logout properly.
Please check whether the ACS URL in the relying party entry related to Stratos IS in the sso-idp-config.xml has the same hostname as in the hostname parameter in carbon.xml.
Thanks,
Thilina

Windows Integrated Authentication fails ONLY if web svcs client is on same machine as IIS server

I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.