I tried to make a production set up (WSO2 MB 3.1.0 and WSO2 ESB 4.9.0) on the same VM.
in order to secure my production environment I changed the default admin psw for the admin user to more secure one. At the same time I created a new MB user (ESB) which I used as "a technical user" in ESB jndi.properties
when I restarted my server I started receiving the following exception in the ESB which tried to connect to the MB:
[2016-10-07 16:47:31,427] ERROR - AMQStateManager Notifying Waiters([org.wso2.andes.client.state.StateWaiter#654a6148]) for error:not allowed
[2016-10-07 16:47:31,427] INFO - AMQConnection Unable to connect to broker at tcp://localhost:5673
org.wso2.andes.client.AMQAuthenticationException: not allowed [error code 530: not allowed]
at org.wso2.andes.client.handler.ConnectionCloseMethodHandler.methodReceived(ConnectionCloseMethodHandler.java:79)
at org.wso2.andes.client.handler.ClientMethodDispatcherImpl.dispatchConnectionClose(ClientMethodDispatcherImpl.java:192)
at org.wso2.andes.framing.amqp_0_91.ConnectionCloseBodyImpl.execute(ConnectionCloseBodyImpl.java:140)
at org.wso2.andes.client.state.AMQStateManager.methodReceived(AMQStateManager.java:111)
at org.wso2.andes.client.protocol.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:517)
I back-traced the problem to the change of the ADMIN psw. When I set it back to the default ADMIN:ADMIN all is working again fine.
any idea why? apparently the psw is not changed on all the places
I followed this article https://docs.wso2.com/display/MB220/Changing+User+Passwords
my configuration xmls does not contain the admin psw however.
thank you very much in advance.
AFAIU, Following are the steps you have followed.
Changed MB default username/password.
Created new user("a technical user") in MB and add these username/password in ESB "jndi.properties" file.
Restarted servers and ESB start throwing auth exceptions.
Things would have gone wrong(at least what I can think of) is as follows :
Somehow you have entered spaces in middle of the username "a technical user"(even it's validated in MB management console)
Solution : Don't use spaces in of usernames.
Even you have created a new user in MB(and added it correctly in jndi.properties file in ESB) you haven't assigned a role which have permission to subscribe to a topic/queue. (This is what most likely you have messed up :))
If you haven't assigned a role which has subscribe permissions to queues/topics ESB won't be able to subscribe with given credentials during transport startup which leads to authentication exceptions.
MB has a role based permission model and if you haven't assigned a user to a role with sufficient permissions user won't be able to authenticate to MB. To verify this theory you can assign "admin" role to newly created user from MB management console under("
Home > Configure > Accounts & Credentials > Users and Roles > Users") and restart ESB server.
Please go through following documentations[1] carefully for more permission/users/user roles related information.
[1]
https://docs.wso2.com/display/MB310/Managing+Queues
https://docs.wso2.com/display/MB310/Configuring+Users
https://docs.wso2.com/display/MB310/Role-Based+Permissions
Related
We recently migrated (registry and user store) from WSO2 IS 5.0 to WSO2 IS 5.1 as per instructions at WSO2 migration guide. After migrating and successfully bringing up the WSO2 IS server, when we are trying to authenticate existing user with /oauth2/token endpoint the authentication is failing. We can see user along with user attributes in user store.
On WSO2 server we are seeing error -
{org.wso2.carbon.identity.oauth2.token.handlers.grant.PasswordGrantHandler} - Token request with Password Grant Type received. Username : <username>#carbon.superScope : openid, Authentication State : false
This is migrated user so we can not change the user name. I tried googling to disable the multi tenancy with 5.1 as we do not use that feature, but no luck.
This is blocking us from moving to newer version of WSO2.
Has Any one fixed this?
Modified the SP to disable domain name as per instructions from Gusto2 -
enter image description here
But still same results.
on the duo identity provider configuration page, under federated authenticators, put "true" in the "disable tenant domain" box
This solution may help. You can go to your identity server and navigate to the service. Now click on edit button of your target service and go to Local & Outbound Authentication Configuration section and uncheck following options-
Use tenant domain in local subject identifier
Use user store domain in local subject identifier
I am showing in the image. Follow the red mark box -
I recently updated my environment from WSO2 IS 5.0.0 to WSO2 IS 5.2.0. My environment consists of 2 machines that are creating a cluster (using the WKA membership scheme and Load Balancer(AWS ELB) with sticky session enabled). I am using MySQL(not the default H2 database). The machines on which the IS is deployed are Windows Server 2012 R2 (EC2 AWS machines). I am also using the so called WSO2 IS Admin services.
As mentioned in the heading I am consuming the UserProfileMgtService
(https://url:port/services/UserProfileMgtService?wsdl).
In combination with it I am using OAuth2TokenValidationService
(https://url:port/services/OAuth2TokenValidationService?wsdl).
If I pass valid access token to the OAuth2TokenValidationService I am able to fill in with data OAuth2TokenValidationResponseDTO object by using the Validate method of the OAuth2TokenValidationService. As result I am able to extract the authorizedUser and pass it to the getUserProfile method of the UserProfileMgtService. I am using the standard carbon.super domain and I am using the email as username. For example I am passing the following two parameters to the getUserProfile:
"admin#admin.com#carbon.super" as username
"default" as profileName
And as result I receive the following message:
UserNotFound: User admin#admin.com#carbon.superdoes not exist in: PRIMARY
If I remove the "#carbon.super" from the authorizedUser, everything is fine and I am able to get the user profile information. This is quite important for me since I am using multitenancy of the IS and there is a case that I might have the following users:
admin#admin.com#test.net
admin#admin.com#test2.net
I noticed that this service was not working this way in WSO2 IS 5.0.0. I started experiencing this issue after the upgrade.
Is this a desired behavior and is introduced because of the change in the API in IS 5.2.0? If so is there another way to be able to get the user profile using the "username"+"tenant-domain"(that is retrieved by the OAuth2TokenValidationService as authorized user when passing valid access token).
Is it possible that this is caused because of misconfiguration? If so which is the file that needs to updated and what exactly should be modified in it?
Is there a place where more information could be retrieved for the WSO2 IS 5.2.0 Admin Services?
Thanks in advance.
UserProfileMgtService in Identity Server is an Admin Service. In WSO2 Admin Services, the tenant domain is identified by authenticated user and it should not pass with username.
username should be tenant free username.
So, you can remove carbon.super portion from the username and then it will work.
In tenant setup, you need to authenticate with a tenant user (Ex admin#admin.com#test.net) in order to access these API. So, like in the super tenant, you can use tenant free username and then it will work.
For example, if you want to get user profile of user : testuser#admin.com in tenant domain test.net, your request should be like bellow image.
Thanks
Isura.
We have the WSO2 API Manager deployed and working, although we are unable to figure out an issue about users addition. We want to add the users via the management console (Carbon) and after being added we want the user to receive an email saying that his/her account was successfully created.
Although there is documentation for a workflow extension when the user signs up, we were unable to find any documentation regarding the matter we've pointed out, is this possible to achieve via the API Manager or with some kind workflow extension?
Thanks in advance!
EDIT: We are using WSO2 API Manager 1.10.0.
If your requirement is to create a user through the management console and allow the created user to define a password, you can configure APIM server to support 'Ask password from user' feature. (In this feature, APIM server administration can create a user through the management console and provide the email address of the user, so that user can set the password through the redirection URL provided in the email). To configure 'Ask password from user' feature follow the instructions given in https://docs.wso2.com/display/IS510/Creating+Users+Using+the+Ask+Password+Option.
If you want the APIM server administrator to set the username and password through the APIM management console and only send a notification to the user that his/her account is created successfully, then you have to write a custom component, because this is not supported by default.
Having WSO2 IS 5.0.0.SP1 backed by PostgreSQL there is another application reading user information using the SCIM service (filter=userNameEq...)
All works but after certain time the service returns "User is not authorized.." response with a single ERROR level log line. Since that moment all subsequent calls fail with "404 User is not authorized". Even when I log in using the admin account I have no access rights. This state takes for a few minutes and then all seems working again.
We traced the response message to the SCIM service implementation where the authorization is checked. However we are unable to find the root cause of the issue (suspecting some exception is qietly dropped, cache cleanup cleans more than it should, ...)
Any hint / idea is appreciated.
Carpe diem
Gabriel
This seems to be authorization issue. If after trying 3 fail login attempt user locked 0-minutes(Most user used 05 minutes). This is default settings of fresh WSO2 IS pack. After the configured locked-time user unlocked. Then the user have a login with valid credentials. If you need, you can change the login attempt,locked time.Please check [IS_HOME]/repository/conf/security/identity-mgt.properties file. It's having the all configuration.
Issue is resolved (or - reason is identified in another system). In the AD tree one of the domain controllers is external (cloud) and unable to authenticate the technical (wso2) datastore user. When the AD node hostname is resolved to the cloud node, then ldapsearch is unable to return any groups from a sub-domain of the cloud based domain controller (interesting - it doesn't fail).
I use WSO2 5.0.0 as IdP and the user store is an Active Directory (AD). User and Roles are listed in WSO2 Management console and I'am also being able to login in WSO2 with User/PW stored in AD.
Therefore everything works fine.
The only problem I have is that if I request roles of users (e.g. over RemoteUserStoreManagement- WebService with method getUserClaimValues) than I get the WSO2 roles and not the Active Directory Roles assigned to the users in the AD. Also only the WSO2- Roles are mapped to users in WSO2.
Actually I have only basic knowledge in AD (I haven't adjust the current connection between WSO2 and AD) - therefore I have no idea where I should have a look at in order to resolve this problem.
Has anybody a hint concerning this issue (user-mgt.xml or WSO2 console or ...)
Thanks a lot for help!
So, you need to retrieve the roles of the user? According what you have mentioned, Please do following to resolve this issue.
Please add following attributes under user store manager configuration in user-mgt.xml file, if there are not with the configuration.
<Property name="BackLinksEnabled">true</Property>
<Property name="MemberOfAttribute">memberOf</Property>
Please restart the server and verify.
Please enable the debug logs in the user kernel and verify where is the issue has been generated.
To enable logs,
Locate log4j.properties file which can be found at /repository/conf directory.
Add following entry in to the file
log4j.logger.org.wso2.carbon.identity.sso.saml=DEBUG
Restart the server and try to invoke the server. You would see LDAP related logs where it would help to identify the issue.