I am new to wso2is, and I'm trying to add the extended schema to SCIM user management as described in http://docs.wso2.org/display/IS460/Extensible+SCIM+User+Schemas+With+WSO2+Identity+Server
I was able to successfully enable the extended schema in the configuration file, do the claims mapping and even successfully create an user with extended claims, but the problem is that when I request the user information back through the /User/ or /Users endpoints, I can't find a way to have the extended attributes included in the result, which always contains only the standard SCIM schema attributes.
Any suggestions?
I think you have mapped your claims to http://wso2.org/claims dialect. But you need to map those claims under the urn:scim:schemas:core:1.0 dialect. Once you map these under the urn:scim:schemas:core:1.0 dialect, GET request populate the extended claims as well.
Regards,
Venura
Related
As part of WSO2 identity server 6.0.0, SOAP APIs are deprecated and recommended to use REST-based APIs. We are using RemoteUserStoreManagerService.wsdl and UserIdentityManagementAdminService.wsdl SOAP APIs in our project, want to replace the SOAP APIs with recommended REST APIs. Can you help us to find the list of REST APIs to replace RemoteUserStoreManagerService.wsdl and UserIdentityManagementAdminService.wsdl SOAP APIs. The APIs document is not clear.
We are unable to find the replacement for the claim management APIs which are specific to user.The APIs which are provided for the Claim management are not user specific, we want to retrieve/create/delete the claims by passing username or userid in the request payload.
Can you please provide the details that are such APIs available for the claim management.
The REST API that you have mentioned matches the ClaimMetadataManagementService.wsdl https://is.docs.wso2.com/en/5.11.0/develop/managing-claims-with-apis/
The only available REST API to manage user claims (retrieving, updating, deleting) is SCIM 2.0 Users APIs https://is.docs.wso2.com/en/latest/apis/scim2-rest-apis/#/Users%20Endpoint/getUser
The thing you have to keep in mind is that SCIM is a protocol that is used for user management. Even though you directly used the local claim URIs in SOAP services to manage user claims, in SCIM API calls you to have to use the respective SCIM claim that is mapped to the local claim.
Check the SCIM Claim Dialects by navigating to management console -> Main -> Identity -> Claims -> List.
There you can find the SCIM claim to local claim mapping
eg:
Get Specific user's name, username claims. Required attributes should be added to attributes param based on the SCIM protocol:
GET https://localhost:9443/scim2/Users/<user-id>?attributes=username,name
Add user claims:
Refer https://is.docs.wso2.com/en/latest/apis/scim2-patch-operations/#add-user-attributes
and https://medium.com/p/1c43bb218658
Delete user claims:
Refer https://is.docs.wso2.com/en/latest/apis/scim2-patch-operations/#remove-user-attributes
and https://medium.com/p/1c43bb218658
A similar issue was raised here. Check the first answer.
The doc that you have referred is to manage the claims in general. Refer to the introduction paragraph.
The API overview page contains all the information about all the APIs you need. The following image shows the APIs needed to mange users, roles and groups (More than what you have asked in the question).
NOTE: Better not to use SCIM1.1
In my WSO2 Identy Server (v5.8.0), i have added one custom attribute named XXX.
Then, in my web client application, I invoke /scim2/Users service to create new user inside IDS.
I successfully create user with correct name, surname, email, phone number and so on, but my custom field is not updated in my user content store.
By other hand, if I update field by data entry and read my user from IDS, I can see my custom attribute XXX correctly.
Can someone help me ?
One of the following reasons could be caused not to update custom attributes via scim2/Users endpoint.
Once you add a new local claim and if you want to access/modify its value using SCIM endpoint it should be mapped to scim claim dialect. Follow the steps in extending scim user claims doc in https://docs.wso2.com/display/IS580/Extending+SCIM+2.0+User+Schemas
If the above step is correctly configured, check the request payload whether the attribute is correctly defined in the payload. If the attribute is not defined in the expected format, WSO2 IS ignores those attributes.
When you trying to update the value via login to the management console and view the user profile through the management console doesn't involve the SCIM APIs. You are directly updating the local claim in the WSO2 local claim dialect. If you have followed the doc mention is step 1 and that attribute has a value, GET /scim2/Users/{user-id} should return the attribute in the response.
I have added a local custom claim namely http://wso2.org/claims/fg_imprenditore to http://wso2.org/claims dialect and mapped it on a custom primary user store attribute (JDBC user store).
The custom claim appears in the user profile and I can set/update the value correctly.
I have defined a new service provider and added the custom claim in Claim Configuration -> Use Local Claim Dialect.
In addition I have edited /_system/config/oidc and modified the openid property to include the new claim as follows: sub,...,street,http://wso2.org/claims/fg_imprenditore
Now the issues.
I ask a JWT Token from a javascript client with the following request:
http://**********/?response_type=id_token&client_id=" + "f8SatEWpyi1qvPLVspsDfTbefm0a" + "&scope=openid&redirect_uri=http://localhost:3000/oauth_callback.html&nonce=" + nonce
After login the WSO2is server prompts the following message (even if the attribute is already present in the profile): You are trying to login to **** application, but it needs following information filled in the user profile. You can fill those below and proceed with the authentication. But it is advised to fill these information in your Identity Provider profile in order to avoid this step every time you login.
If I fill the field (correctly) labeled "http://wso2.org/claims/fg_imprenditore" I can proceed. In any case the claim is not returned in the JWT Token.
In addition if I go in the user profile the attribute is set correctly (with the new value!) but if I try to authenticate again I need to fill the attribute again..
Many thanks for the support.
If you don't mark the claim as mandatory on your Service Provider it shouldn't request it when you try to log in. Also, in order for the jwt to contain your custom claim you need to map the custom claim to a new custom claim under the oauth dialect, and then map the new oauth claim under the oidc scope you use. It took me a while to get it too as there isn't sufficient documentation describing these steps. Hope this solves your issue.
This happens because "http://wso2.org/claims/fg_imprenditore" claim is not mapped to any oidc claims in WSO2 IS. Do the following in get rid of the issue.
Go to List under Claims in IS Management Console Main tab.
Click on http://wso2.org/oidc/claim
Add new claim with the name fg_imprenditore in oidc claim dialect. You will see a drop down to select "Mapped Local Claim". Map it to http://wso2.org/claims/fg_imprenditore. (Check "Add External Claim" section in this)
Save new oidc claim and try again.
After performing the authentication against the WSO2 IS 5.0.0 and negotiating the access token, I perform a call to the userinfo endpoint:
https://:9443/oauth2/userinfo?schema=openid
It answers correctly with a JWT, but using always the dialect http://wso2.org/oidc/claim even if another dialect is configured in the in the identity.xml (for example http://wso2.org/claims)
It seems like the userinfo endpoint ignores the dialect configuration. Does anybody else has faced this problem?
Is it a bug or am I missing something?
I think this is not a bug. because by default Openid claim dialect returns userinfo(oidc) according to the Openid Specification.WSO2 uses default claim dialect to retrieve userinfo as wso2 calim dialect. But this wso2 claim dialect should be mapped with OpenID claim dialect (http://wso2.org/oidc/claim).
If you want to retrieve userinfo additional than default info, you need to map "http://wso2.org/claims" attributes with "http://wso2.org/oidc/claim”. Otherwise it returns by default mapped properties only ("phone_number", "email", "family_name" and "country").
Below steps are to retrieve ‘mobile’ as a claim though it is not configured as default
Go to the "Claim Management" under "Configure" tab.
Then click "http://wso2.org/oidc/claim" and check whether this "Mobile" claim is available or not.
If it is not available, you need to add New Claim mapping.
If this "Mobile" claim is already exist, you need to check whether that mapped attribute is equal with "http://wso2.org/claims/mobile" Mobile mapped attribute.
(Note:http://wso2.org/oidc/claim particular mapped attribute should be equal with your http://wso2.org/claims particular claim attribute).
Like this you can map "http://wso2.org/claims" particular claims with "http://wso2.org/oidc/claim" claims.
I'm running the wso2is-4.6.0
I've created a policy like allowing a user with a specific role to access a resource.
When I TryIt, the wso2is manager just propose me a Subject Name (urn:oasis:names:tc:xacml:1.0:subject:subject-id). I've seen in previous version of wso2Is see here that it was possible to define a Subject Attribute Name (in my case it would be http://wso2.org/claims/role).
The result is that I can't test my request with the current version as the attributeId generated by wso2 tryIt tool refer to a subject-id where I need a http://wso2.org/claims/role
Any way to have this Tryit page more customizable ?
Thanks for your help and support
Regards
Vpl
TryIt is a simple tool that you can create the XACML request. It can not support all options that are available. However when its some to new version, It seems to be that attribute Id selection has been removed. But you can file the attribute values and create the sample XACML request in XML view. Then you would find that the attribute id of created XACML request would be urn:oasis:names:tc:xacml:1.0:subject:subject-id. Therefore you can easily modify it to http://wso2.org/claims/role and try out the policy.