Configuring WSO2 Identity Server as Key Manager with API Manager - wso2

I'm looking for some guidance about two specific WSO2 products, API Manager and Identity Server and for the best solution to solve the problem I'm going to explain below.
In my company, we are using ADFS 3.0 for Single Sign On support in our applications. However we are now building applications that will require OpenID Connect Specification (SPA's+Rest API's) and ADFS does not support this out of the box so we've decided to use WSO2 products for that purpose.
I already managed to install WSO2 Identity Server 5.0.0 SP1 and configured ADFS as a federated Identity Provider (the new applications will still have to authenticate users using ADFS). I also installed WSO2 API Manager 1.9.1 and configured it to use WSO2 Identity Server as the Key Manager (Configuration tutorial).
Now the problem:
Using WSO2 Identity Server 5.0.0 SP1 I couldn't get the Logout feature to work due to the issue reported here. It seems that this issue has been solved in version 5.1.0M4 so I tried to install version 5.1.0-alpha and managed to make the logout to work with ADFS (I tested it by enabling SSO for the carbon administration). However, now I'm not able to install the Key Manager feature through the carbon repositories due to incompatibilities.
As a result, with the first combination (wso2is 5.0.0 SP1/wso2am 1.9.1) I had the logout issue with ADFS and with the second combination (wso2is 5.1.0-alpha/wso2am 1.9.1), I'm not able to install the Key Manager feature in Identity Server.
Is there any way to apply a patch to solve the logout issue in the first combination? Is there a way to install the key manager feature on WSO2IS 5.1.0-alpha? Or can someone point me to another solution to solve this issue?

The issue you pointed above, marked as it type as "Patch". Usually that means WSO2 have fixed this issue for a earlier version and provided a patch to its customer. Easiest thing would be, if you are already a customer of WSO2 ask for the patch directly from their support.
If you are not a paid customer of WSO2 you are in bit of a trouble. As per this question, the source of the Service Pack also not available in public.
But luckily in your case, the component which need to have this fix not a core component. So you wouldn't be in trouble if you change the authenticator code bit. But the warning is, it would lose any fixes done for org.wso2.carbon.identity.application.authenticator.samlsso_4.2.1.jar in the service pack.
Anyway, these are the steps you should follow.
Checkout the source. Lazy path would be checkout the whole source from here. That is the most easy way which you will face less troubles when you try to build the source but the downside of that is, it would take bit of time to checkout. If you know how to build specific component from WSO2 source, you can directly checkout component it needed to changed.
Try to build the component without doing any change just to make sure there are not any issues upto this point.
Goto the class DefaultSAML2SSOManager and do the same change done in the PR.
Build the component again.
Create folder named like "patch9000" inside the <IS_HOME>/repository/components/patches/ folder.
Copy build jar (org.wso2.carbon.identity.application.authenticator.samlsso-4.2.1.jar ) in step 4 from the target folder to the <IS_HOME>/repository/components/patches/patch9000 folder.
Restart the server. If you have done everything to the point, in the server startup it would print a log like, org.wso2.carbon.server.extensions.PatchInstaller - Patch changes detected
Now retry the your flow and it would work as expected.
If you too lazy to do all above, you can wait until Identity Server Service Pack 2, which will have your fix.

Related

Detecting PCF version(s)

I have access to our corporate PCF, though both the Apps Manager webpage and the "cf" CLI (and thus the API).
How can I detect what version of PCF they're running? There's nothing in the website that lists it, and the best I can find is using cf api which returns:
api version: 2.98.0
How can I map that to the PCF version, or is there another way to detect it?
Usually via Ops Manager however another quick way is to click on the 'Docs' in Apps Manager it should take you to the documentation of relevant PCF version. For ex: https://docs.pivotal.io/pivotalcf/2-6/pas/intro.html means PCF 2.6
Please be advised that documentation link requires to be updated during upgrades so if someone doesn't do - it will be pointing out to older version..
I don't believe Apps Manager or the API (i.e. Cloud Controller) will report that information. Both are just single parts of the entire system, so I think you could really only expect them to publish their own version information.
If you want to see versions of what is installed, you need to look at Ops Manager. That will show you the tiles that are installed and each version.
If you don't have access to Ops Manager, you'd need to ask your platform operators.
Hope that helps!

Error Configuring WSO2 data analytics server

I'm currently experimenting/working on WSO2. What i'm trying to do is to have Data Analytics server configured. I started by following the below specified URL
https://docs.wso2.com/display/AM210/Configuring+APIM+Analytics#9d6747f5c0074928b18599abe472987d (Quick Steps)
After performing all the steps, i get the following issue on APIM cmd prompt
YES Its pretty evident from the error that no such table exists BUT that is exactly the issue i'm facing. What could really be the cause here?
Consider the following points:
I've not followed ALL the steps mentioned on
https://docs.wso2.com/display/DAS310/Getting+Started (BUT are they
required?)
In the installation prerequisites for DAS, JDBC-compliant Connector for Java is required which I've not yet installed (BUT its not mandatory at the same time)
Most of the QUICK STEPS for the configuration of DAS in the specified URL i.e. https://docs.wso2.com/display/AM210/Configuring+APIM+Analytics#9d6747f5c0074928b18599abe472987d where already in place and i only had to
Set Up JDK, ANT, Maven
enable the analytics section in the API-M_HOME/repository/conf/api-manager.xml
add log4j.rootLogger=, DAS_AGENT to API-M_HOME/repository/conf/log4j.properties
add snappy-java_1.1.1.7.jar to DAS_HOME\repository\components\lib
Yet the issue persists, Do let me know of what you think. Thank you
Since you are following quick start guide please extract the WSO2 API Manager and the WSO2 API-M Analytics distributions (zip files), to the same directory (preferably an empty directory).
Also, you need to generate some traffic to the published APIs in order to analytics server to create this table for the first time.

WSO2esb-4.8.1 issue with GUI for viewing Logs

We are using WSO2esb-4.8.1.
We want to use the WSO2 GUI to view the tenant specific log. But we are getting the following message always when we navigate to Monitor--> Application Logs.
The log must be configured to use the org.wso2.carbon.logging.core.util.MemoryAppender to view entries on the admin console
I found that in the log4j.properties, the following is used
log4j.appender.CARBON_MEMORY=org.wso2.carbon.logging.appender.CarbonMemoryAppender
I changed this to
log4j.appender.CARBON_MEMORY=org.wso2.carbon.logging.core.util.MemoryAppender
The issue remains though.
By default, when you install WSO2 4.8.1, Esb, it installs the Logging Management 4.2.1
With this, the logs are visible in the GUI. It works as expected.
But later, if you install any other feature , that includes a higher version of logging management (eg:- in our case, we installed data services 3.1.1 that includes logging management feature 4.2.2), the GUI stops working.
All I did was unchecking the logging feature in data services 3.1.1 when installing data services. This way, the logging feature did not get upgraded, but the rest of the data services did.

jUDDI Installation and configuration

I have installed the basic jUDDI Server in my machine. I am able to Register the Service and able to read my Service info as a new user. I want to restrict the users who wants to look up my services. I want only my clients to access these information. I want to authenticate them so only my clients can view the business, service, tModel, Binding Template information. How can I achieve this? Can any body help me get through this?
Try turning on the setting the requires authentication for the inquiry API. You can find it in the juddiv3.xml config file for the server. Here's the xpath to get you there.
config/juddi/auth/Inquiry=true
Future readers, the documentation is located here for the current release (as of this time of this post)
https://juddi.apache.org/docs/3.3/juddi-guide/html/ch04.html#_administering_users_and_access_control
but the website https://juddi.apache.org/docs.html will get you to whatever is current. The docs (that website) is also available as part of the distribution and (i think) maven artifacts

Wso2 ESB don't deploy car

I am trying to remove the car of an Aplication.
I removed the .car by management console and removing the file in wso2esb-4.0.3/repository/deployment/server/carbonapps but wso2 dont put nothing in the log and dont remove the artifacts, I cant shutdown the server.
When I remove de .car and upload the file again the server dont re-deploy anything
The initial problem was that some artifacts had disapeared from management console, but the .car was deployed, a other instance of the .car are in the temp directory.
This was a known issue [1] and fixed from WSO2 ESB 4.5.0. I think its recommended to use the latest version of the product since in that case many bugs fixed and many new features are added to the product. You can find the latest distribution of WSO2 ESB 4.7.0 latest release here [2]
Hope this will help you.
[1] https://wso2.org/jira/browse/ESBJAVA-940
[2] http://wso2.com/products/enterprise-service-bus/
We had this problem too. It can also happen when you have deactivated a proxy within the web console.
Be sure all components from the specific .car file are running.
Uninstall the application (within the web-console)
Wait until all components are gone
If this is not working - you need to stop the server and remove all components (from that .car) from the file system manually. We did that a couple of times and it worked. (search for all affected components and remove them).
We finally solved the issue by upgrading to a new version of WSO2 ESB.