I'm evaluating WSO2 5.3.0 so I installed the product on premises. Inside the Super Tenant, I created a sub-tenant TA.
When Connecting to TA with the admin associated to it, I try to create users. It always fails with the error
Could not add user PRIMARY/jfo. Error is: Password pattern policy violated. Password should contain a digit[0-9], a lower case letter[a-z], an upper case letter[A-Z], one of !##$%&* characters
In fact it seems that this is a password policy issue because if I set "admin" as password the error is
Could not add user PRIMARY/JFO. Error is: Password at least should have 6 characters
But it does not work even with "Admin123!" as password value for the account. and from my check :
- Password policy is not accessible (nothing is displayed) in TA when I go to Identity Provider/Resident
- Password policy is not activated in the Super Tenant and it is validated as I can create users with the password "admin" with no issue nor warning.
- All others parameters are set to OOTB value.
Does anyone has an idea ?
Thanks
JF
It seems that it was an error at creation of my first tenant cause the Identity Provider / Persistent pane is empty on the faulty tenant. It prevents me for accessing the Password Policies pane for example.
Deleting the faulty tenant and recreating it solved the problem. I, on other hand, did not get any reason or source of the faulty creation.
Related
I am new to AWS cognito. I have a requirements to manage users though AWS cognito.
Users can sign themselves up
I am using hosted UI to achieve this.
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-app-integration.html
Only admin can confirm user from AWS console.
User is getting created with Unconfirmed status (expected).
Everything works as expected, but at the time of sign up, hosted UI responds with "An error was encountered with the requested page".
I don't want user to be auto approved and hence not invoking pre sign up lambda.
Please find attached image error.
Is there any way I can display custom message like "User is created, please contact admin for user confirmation" ??
Thank you .
The issue is occuring probably because you chose Allow users to sign themselves up and did not chose any verification type - No verification.
Choose Only allow administrators to create users or any verification type to avoid this issue.
I've successfully applied a custom password policy for my IAM users in AWS:
aws iam update-account-password-policy --minimum-password-length 64 --allow-users-to-change-password --password-reuse-prevention 24
Next I force a password reset - this also works.
But the when I deliberately try to set the new password to a non-compliant one, I get this rather opaque error at the top of the page (https://us-east-1.signin.aws.amazon.com/changepassword):
Either user is not authorized to perform iam:ChangePassword or entered password does not comply with account password policy set by administrator
Is there a way to configure useful feedback? Such as: Password should be at least 64 characters?
There is currently no way to customize this error message. There is an AWS Developer Forums thread from 2017 that raises this issue, however the response appears to have only been to add "or entered password does not comply with account password policy set by administrator".
Unfortunately your only option is to communicate password complexity requirements through a parallel vector. Alternatively, if you create accounts by setting a temporary password for the user instead of requiring a password reset, you could (outside of AWS) template an email to send that to the user that includes instructions on password complexity.
The API does actually clarify whether it was a password policy issue, however.
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?
I have this problem when using SAML SSO authentication. I have successfully set up WSO2IS 5.0.0 Identity server, I also succeeded setting up (at least I hope so) secondary user store. I used JDBCUserStoreManager implementation. I have set this store as DOMAIN. This user store works nice, at least I think it does. Because it is storing user attributes into its tables (USER_ATTRIBUTES) and those attributes are read by WSO2IS administration ...
https://localhost:9443/carbon/userprofile/edit.jsp?username=DOMAIN/demo_jbu&profile=default&fromUserMgt=true
Users are identified as DOMAIN\username so when I want to log in user from this DOMAIN, request goes to my AUTHENTICATOR implementation so I can manage authentication for users from this domain.
What is strange is, that if I use WSO2IS administration pages, I can set and read users's attributes well. And if I use SAML SSO authentication (have already set up service provider & claim mappings) for users from PRIMARY domain, everything goes fine and calling SP gets all attributes - mapped in WSO2IS administration here:
https://localhost:9443/carbon/application/configure-service-provider.jsp
If I use SAML SSO authentication, but I want to log user from my DOMAIN, SP doesn't get anything.
I can override this behavior in DefaultResponseBuilder, I can put into SAMLResponse anything I want, but I don't feel this approach is OK. Can anyone tell me, where to look for an error? What may be wrong? Where should I start looking for problems? I have already tried to debug it, and it seems it (SAML SSO/AUTHENTICATOR) doesn't find any claim for DOMAIN user.
Thank you in advance.
Josef
I think this is bug in Identity Server 5.0.0. When you are using SAML2 SSO, user can login to Identity Server with both username with domain name and username without domain name. Basically
bob and foo.com/bob must both works and returns the bob user's attributes from foo.com user store. However there is issue with IS 5.0.0, if secondary user store user login without domain name, Identity Server does not returns the user attributes. But, please try to login with foo.com/bob , Then it would return the user's attributes.
You can find the public jira. It contains source diff. It must be a simple fix and you even can compile the source and add fix in to the Identity Server.
I have been fighting an issue for awhile where I cannot get our application to work with a secondary user store (AD) without specifying the domain name. AD user/role enumeration is working fine, and I am able to login to the WSO2 admin console with an AD account (username only!) granted admin rights via an AD group, so if that works, then I would think the entitlement service would too...
I have determined the reason for this is that while I can login to the application (and WSO2 admin console) with the AD username only, the role assignment is not being picked up by the application unless I specify the domain with the account (domain/user), as confirmed by using the PEP/search tool. If I use the domain/user in PEP search, I can see the entitlements.. if I use the username only, I don't. My XACML is defined to use domain/group for the role. It's worth noting that if I use an internal role with an internal user and applicable XACML policy, the application works perfect.
This looks to be the same bug as for 4.2.0 (https://wso2.org/jira/browse/CARBON-14861) but I cannot find anything similar for 4.5.0. Does anyone know of a way around this other than making my LDAP user store primary?
TIA!
Idea is that, when you are using XACML with multiple user stores feature of Identity Server, you need to send the username with domain name. Therefore, when you are searching, you must set the username to domain/user
I think it is fine, because authorization happened after the authentication. When authenticating, somehow, user's domain name (user store which user has been authenticated) can be known.
The issues that has been referred, is a separate issue.