Creating read-only user in WSO2 ESB - wso2

I need to create a read-only user can not modify APIs, Sequences, Templates and Log configuration.
Is it possible through User Management in WSO2 ESB 4.8.1?

Currently WSO2 Carbon user management framework does not provide users with a read only permission for source view. I have attached a screenshot that exhibit the permission set that need for ESB mediation developer, Since "mediation" permission does not have any further fine grained permission set, your request can not be fulfilled. This is a improvement to be done.

Related

WSO2 Identity server - multiple tenants on service provider side

Application I inherited uses WSO2 Identity server which I have't used before. I might need to support multiple tenants in this application and I need to research if WSO2 IS will support this. Documentation is not helping me unfortunately. I want all tenants to have same, shared roles. Adding new tenant should mean adding it's users and assigning them already existing roles.
So in my head solution should be rather simple. Just add new field to user profile - tenantId, and then return it as a claim in token. When I have it in token then it's up to code to use it. First of all is this possible at all? If it is it a good idea?
There are two other possible solutions I was considering.
Service Provider has SASS checkbox but I don't understand yet how it works.
You can add tenants to WSO2 IS itself. But to me it looks like it is multitenancy on WSO2 IS side (to share WSO2 IS) and it's not a feature to support multitenancy in my application. I was told that in this case each tenant would have to have roles defined again and that even those roles would have to be named differently.
WSO2 Identity Server do have the IDP level tenant separation but it does not have an OOB SP level tenant separation mechanism. However, your proposed solution can be done. It is a simple configuration to add an extra claim to the user [1](Assumes that the underlying user store supports it).
Answers for your other questions,
It is for IDP level tenant separation and if you need to share SP between those tenants, you can use this check box.
Correct.
This will do a clear separation in the IS side so data will be contained to each tenant. However, you can share user stores between each tenant.
[1] https://docs.wso2.com/display/IS580/Adding+Claim+Mapping

WSO2 EI (ESB) communicate with WSO2 IS

I am new to this software. From what I know, the WSO2 Enterprise Integrator is come with Enterprise Service Bus inside it. But the Identity Server (IS) is not bundled with the EI.
For my current and new project, we going to be used both of it inside the architecture. Please see below diagram for more information.
Part of my project architecture
Based on the diagram, when the user is using the portal to login. The EI is serve as the middle-ware between the portal and the IS to connect to the LDAP.
Looking at the documentation, there is way to connect from IS to the other product but not vice-versa.
My question right here is how to allow the ESB to communicate to the IS and return back the message/request to the Portal.
Thank you.
Yoy did not describe your use case what do you want to achieve so I will assume you want to authenticate the portal user or manage users.
WSO2IS (and effectively any wso2 product) exposes admin services, some are common, some specific to the product. The services require basic authentication.
please see https://medium.com/#maheeka/wso2-admin-services-c61b7d856272
Another service to authenticate a user is a token service with password grant (that may be more appropriate to authenticate users and authorize requested scopes)
Just a note:
If you want to use the whole setup only only to authenticate users, then IMHO you rather may use OAuth or SAML with the IS, not passing passwords in ESB

wso2 products - log user actions done in Carbon console

We have some security requirements from customer, so we need to configure/develop detailed audit logging which will log user actions done in Carbon Management console - i.e. datasource modification, service modification in WSO2 ESB.
Is there any way do this using included log4j?
We are using WSO2 Enterprise Service Bus 4.8.1 and WSO2 Application Server 5.2.1
WSO2 products has an audit log which can be found in the repository/logs folder. But the problem is, this audit log has very little audit information. Reason is as follows.
WSO2 products are built using a collection of reusable osgi componentns. For example, for data sources related operations we have one component and for proxy related operations we have another.
Now, the problem here is, these individual components has not put enough audit logs to cover the user operations. Therefore, your requirement seems to be difficult to achieve.
There are some extension points in WSO2 products where you can use to do your own tasks upon certain actions such as user login, user creation. For example, you can implement a certain interface and print whatever log you want upon a successful user login or a failed login attempt. But, those extension points are limited mostly to user management related operations.
All the HTTP communication done with the server is already logged in HTTP access logs in CARBON_HOME/repository/logs. You can use a log analyzer tool or even grep to capture any desired user action.
Ex: To get the log ins to datasources page use
cat http_access_2016-06-02.log | grep "GET /carbon/ndatasource/index.jsp"

Publish and subscribe an application as an API in WSO2 AM-1.7.0

I have a Timesheet Entry application which needs to be exposed as an API which the users shall use for entering their effort time for assigned tasks.I have the following queries:
I have the login authentication created as a restful client which I have published and currently subscribing with JSON message as response.How to open up this service in the UI, so that the user gets the usual page for the authentication.
How to access this API from different user systems?Does the user has to login to the WSO2 Store everytime he wants to use this API?
The WSO2 docs mention to create users and roles, but since there will be around 10K users for this, how to do this to make the user feel that its the same application as before?
Users are not required to log into the store. Only the application developer has access to the store.Application developer gets the consumer key/secret pair from store and embeds it in the web Application.
Application users/subscribers do not need to be aware of the API store. When they use/login to the application, access tokens can be generated using the embedded consumer key/secret pair based on a specific grant type ( Eg: Password) and access the service exposed via the API.
It is not required to create users and roles manually. If there exists a user store , you can integrate it with WSO2 API Manager. [1] explains how to integrate a user store.
You can refer to the sample [2] to get an idea of how this is done in WSO2 API Manager.
This sample demonstrates a scenario where various services of a deployed web application are accessed via APIs created in API Manager.
[1] https://docs.wso2.com/display/AM170/Configuring+User+Stores
[2] https://docs.wso2.com/display/AM170/Invoking+APIs+using+a+Web+App+Deployed+in+WSO2+AS

Recommendation for integrating WSO2 API Manager, Identity Server and Shibboleth

What is the current, recommended way to setup a WSO2 API manager to use SSO against a Shibboleth IDP?
Our organization has an existing SSO infrastructure built around Shibboleth’s IDP which we would like to integrate into our API Manager installation. Ideal Use Case:
User navigates to API Manager Store.
User is redirected to Shibboleth IDP Login page.
If one doesn’t exist, an API Manager Account is created and assigned the Subscriber role.
User is returned to API Manager and logged in. “Signed-in-as:” renders a reasonable user name (i.e. not a GUID).
I’m aware that there is an included SAML2 authenticator component to the API Manager but it is limited in features, specifically it does not handle Encrypted Assertions, Using specific attributes for username/display name and automatic user creation.
I understand that we could write a custom authenticator, however we would rather avoid creating another code base that needs to be maintained and doesn’t have community support. If a simpler solution cannot be determined then this will likely be what we do.
What I am currently investigating is delegating all user management for the API Manager to a WSO2 Identity Server. It IS would delegate authentication to Shibboleth and auto provision users before returning to the AM. The IS seems like it could address all of the issues mentioned above.
Firstly, is this an appropriate strategy? If so, how is it recommended that the AM and IS be configured?
Should the IS and AM both point to the same JDBC Database or should the AM point to the IS’s LDAP server?
Regarding the AM authenticator which is pointed to the IS, should I use SAML or OAuth, or is there a better/simpler one?
Shibboleth IDP v2.4 – SAML2 with Attribute Push preferred.
WSO2 API Manager v1.6.0
WSO2 Identity Server v5.0.0
Here's the results of my research, for anyone interested:
1) This is an appropriate strategy. The new features in the 5.0 release of Identity Server are mainly centered around this scenario. And the 1.7 release of AM also includes features to facility this setup. Finally I've heard from the developers that they intend to push this integration even further in the next few releases.
2) As of AM 1.6 there was a bug which made it almost required to share the same Primary JDBC user store. As of 1.7 it should be more open.
There does not seem to be a preference from the people at WSO2 between LDAP and JDBC (except that the default H2 DB is not designed for production environments), however if you are choosing between installing a DB or Open LDAP for this, a LDAP server seems more suited to the choice.
3) It's best to use SAML for communicating between the two when the goal is to present the user with a UN/PW screen. When the goal is to login with pre-issued tokens then OAuth. The API Manager and IS use both protocols behind the scenes, but the answer to this particular question seems to be SAML.
In the future WSO2 plans to expand the "Trusted IDP" feature of their products, which will streamline this process (and use SAML behind the scenes).