WSO2 Identity Server multi-tenancy errror - wso2

When trying to evaluate policies, I get the following error:
Error while retrieving attribute values from PIP attribute finder : Illegal access attempt to cache ] owned by tenant {[client1.mydomain.com],[1]} by tenant {[client2.mydomain.com],[2]
This occurs after successfully creating policies on client1, and then trying to create policies on client2. This seems to ocurr when testing policies on client2 that involve roles.
Any idea what is wrong?
Thanks

What is the version of WSO2IS? Did you deployed Identity Server in a cluster? Then this may be a know issue. Actually, this can not be configuration issue.. This must be an issue with WSO2IS with using caching... However you can avoid caching issue by disabling it.. Please open entitlement.properties file and disable caches..(Specially attribute cache) And restart the server.

Related

Getting only sub in UserInfoEndpoint

I am just following what is on the guide
I've already populated the user's profile information but so far I only get sub. I want to get something same like in the guide:
{
"sub":"admin",
"email":"admin#wso2.com",
"website":"https://wso2.com",
"name":"admin",
"family_name":"admin",
"preferred_username":"admin",
"given_name":"admin",
"profile":"https://wso2.com",
"country":"Sri Lanka"
}
CONFIG
Identity Server - AWS Cloud with Domain and SSL + Nginx Proxy
Sample Web App - local machine
UPDATE:
It is an open bug. What
is the workaround to get the other fields? Based on that jira, only
the password grant is not fix, where to get the fix for code and
impilict grant?
I tried hosting the IS also locally, same results
To retrieve OIDC claim attributes to id_token or userinfo endpoint, the following steps needs to be done correctly(assuming you are working on IS 5.2.0).
1. Update relevant claims' Mapped Attribute with your underlying user store's matching attributes.
2. Update requested claims to Service provider [1].
3. Update missing attributes in '/_system/config/oidc' for scope 'openid' (Configuration changes in IS 5.2.0 [2]).

Error in WSO2 claims configuration with LDAP(Active directory)

We have done WSO2 IS configurations with multiple LDAPs with multiple clients successfully before. This time with a new client we are getting an error as show in image. "Error occured while getting all user claims for ... in carbon.super.
The case is we have created a service and mapped custom claims to map to LDAP. The issue is with a field mapped with http://wso2.org/claims/role attribute . If we remove this attribute from the custom claims the error goes away.
But we are using roles in business logic(Internal roles created in WSO2) which we get as null in case we remove this attribute.
We want to know the solution. Is there some change required at LDAP side ? Or how we can achieve the roles without mapping as a claim with LDAP?

WSO2 Identity Server SCIM Authorization issue

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).

WSO2 -> Active Directory -> user - role mapping

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.

Configuring Single Sign-On Across Stratos

I have a situation where I need to setup a standalone version of wso2 Identity Server and have that act as the SSO provider into all of the products in Stratos.
Currently I have Stratos Identity Server configured so that I can login via the standalone Identity Server, using admin.
However, if I use another user I either
get a "Authorization Failure"
or cannot login.
First Question
1) I have the same user created in both Identity Server (that is not admin). Why would I get the "Authorization Failure" ?
Second Question
2) Why is it I can not even get to the "Authorization Failure" problem if I have a user created with username in format of user#domain.com ?
UPDATE:
I figured out that if I remove the property tags in user-mgt.xml that reference the usernames with regular expressions I am able to create usernames in the format of name#domain.com. But I am still unable to use that username to login, the error log says that the account has not been activated.
I also created two instances of wso2 identity server and configured them in such a way to test being able to use one to login to the other. I was able to do this by making sure that the same username and password was in both servers list of users. This way I do not get the "Authorization Failure"
The answers I came up with.
1. I need to have the same username and password in each Identity Server.
2. I cannot have format name#domain.com unless I have Multi-tenancy configured. Otherwise wso2 will try to find the ACTIVATE field in the Tenant table and not find it.
UPDATE: I got this installed and configured and it turned out that I now get another error about
Issuer details are not valid. Issuer details should be registered in advance
So my answer turned out not to to be valid.
I wonder why I get this new login failure?
UPDATE RESOLVED!!:
I resolved this problem by downloading just the wso2 stratos IS 1.5.2 package. I installed it. Configured with same configuration I was using before. Now I can login without problems across domains.