Showing posts with label SCIM. Show all posts
Showing posts with label SCIM. Show all posts
Friday, December 7, 2012
Getting started with WSO2 Charon 1.0.0
WSO2 Charon 1.0.0 is released... It is successfully integrated in WSO2 Identity Server 4.0.0 for identity provisioning.
WSO2 Charon is the open source implementation of SCIM specification, and it is made available under Apache 2.0 license.
You can check out my previous blogs which was written around its Milestone 1 release.
In this post, I will provide you step by step guide to play around with it by running the sampels.
Step 1: Obtaining binaries
Two jars are shipped with the distribution. They are:
1. Charon-Core-1.0.0 jar - This is the library that implements the specification and which can be used by any identity management solution to add provisioning capability.
2. charonDemoApp.war - This is the reference implementation of SCIM service provider which uses Charon-Core for SCIM support. It is a RESTful webapp exposing SCIM endpoint which you can host in a servlet container.
You can either obtain these jars from the release distribution or by building the source code.
Step 2: Setting up SCIM service provider
We need two parties to observe identity provisioning capability. i.e: Service Provider and the Consumer. You can use either Charon-Impl hosted in tomcat or WSO2 Identity Server 4.0.0 as the service provider.
My previous blogs explain WSO2 Identity Server's capability as a SCIM service provider. Therefore, here I will explain how to setup Charon-Impl as a SCIM SP.
1. Download tomcat 7.0.11
2. Replace server.xml and tomcat-users.xml [found in tomcat_home/conf] with the attached files here.
4. Place the attached keystore in your file system.
5. Open the server.xml and locate the HTTPS connector. Edit the keystore file location to point to the above keystore.
6. Run the server with sh catalina.sh jpda run.
7. Access http://localhost:8080/ and click on Manager APP.
8. Login with credentials: hasini@wso2.com, 7786htg
9. Upload the charonDemoApp.war which is obtained from step 1 and access http://localhost:8080/
Step 3: Running the samples
1. Compile the source of the charon-samples which is a maven project and found in the release distribution, using the command: maven clean install.
2. Open charon-samples from your IDE.
3 .Go to SampleConstants - here is where all the constants needed to run the samples are hard coded.
i. Change the KEY_STORE_PATH to your file system location if the default one doesn't work. (This is only needed if you use https as the transport)
ii. Change the User and Group resource endpoint urls according to your system.
4. Now access "CreateUserSample" class from your IDE. You will see the constants defined at the top - which are the values for the attributes of the user that we are going to create.
5. Run the client. You will see that the user created at server side is returned in JSON format and printed at client side. (You can observe the message on the wire using a tool like tcpmon, as I have shown in a previous post)
6. In the same way, try other samples as well, paying attention to instructions mentioned as comments in the sample code.
Note: You can also run the same set of samples against the SCIM endpoints of WSO2 Identity Server. The configuration that matches with Identity Server, is kept commented out in the SampleConstants file.
That's it.. Enjoy SCIM..! :)
WSO2 Charon is the open source implementation of SCIM specification, and it is made available under Apache 2.0 license.
You can check out my previous blogs which was written around its Milestone 1 release.
In this post, I will provide you step by step guide to play around with it by running the sampels.
Step 1: Obtaining binaries
Two jars are shipped with the distribution. They are:
1. Charon-Core-1.0.0 jar - This is the library that implements the specification and which can be used by any identity management solution to add provisioning capability.
2. charonDemoApp.war - This is the reference implementation of SCIM service provider which uses Charon-Core for SCIM support. It is a RESTful webapp exposing SCIM endpoint which you can host in a servlet container.
You can either obtain these jars from the release distribution or by building the source code.
Step 2: Setting up SCIM service provider
We need two parties to observe identity provisioning capability. i.e: Service Provider and the Consumer. You can use either Charon-Impl hosted in tomcat or WSO2 Identity Server 4.0.0 as the service provider.
My previous blogs explain WSO2 Identity Server's capability as a SCIM service provider. Therefore, here I will explain how to setup Charon-Impl as a SCIM SP.
1. Download tomcat 7.0.11
2. Replace server.xml and tomcat-users.xml [found in tomcat_home/conf] with the attached files here.
4. Place the attached keystore in your file system.
5. Open the server.xml and locate the HTTPS connector. Edit the keystore file location to point to the above keystore.
6. Run the server with sh catalina.sh jpda run.
7. Access http://localhost:8080/ and click on Manager APP.
8. Login with credentials: hasini@wso2.com, 7786htg
9. Upload the charonDemoApp.war which is obtained from step 1 and access http://localhost:8080/
Step 3: Running the samples
1. Compile the source of the charon-samples which is a maven project and found in the release distribution, using the command: maven clean install.
2. Open charon-samples from your IDE.
3 .Go to SampleConstants - here is where all the constants needed to run the samples are hard coded.
i. Change the KEY_STORE_PATH to your file system location if the default one doesn't work. (This is only needed if you use https as the transport)
ii. Change the User and Group resource endpoint urls according to your system.
4. Now access "CreateUserSample" class from your IDE. You will see the constants defined at the top - which are the values for the attributes of the user that we are going to create.
5. Run the client. You will see that the user created at server side is returned in JSON format and printed at client side. (You can observe the message on the wire using a tool like tcpmon, as I have shown in a previous post)
6. In the same way, try other samples as well, paying attention to instructions mentioned as comments in the sample code.
Note: You can also run the same set of samples against the SCIM endpoints of WSO2 Identity Server. The configuration that matches with Identity Server, is kept commented out in the SampleConstants file.
That's it.. Enjoy SCIM..! :)
Friday, November 9, 2012
Identity Provisioning from On-Premise to Cloud
Quoting from one of my initial posts on SCIM:
"Today the enterprise IT solutions adopt products and services from multiple cloud providers in order to accomplish various business requirements. Hence it is no longer sufficient to maintain user identities only in corporate LDAP.
In most cases, SaaS providers also need dedicated user accounts created
for the cloud service users, which raises the need of proper identity
provisioning mechanisms to be in place."
Identity Server(IS) 4.0.0 which is a 100% open source Enterprise Identity & Entitlement Management Server, supports the open standard SCIM for identity provisioning as I have mentioned in my previous posts as well.
With this, WSO2 Stratos Live next release will also be supporting SCIM for Identity Provisioning.
This post is about implementing a use case of identity provisioning from on-premise to cloud using Identity Server and Stratos (here, same IS distribution can be used to simulate Stratos IS with multi-tenancy aspects).
Following diagram gives an overview of the deployment:
Use case:
Two organizations called wso2.com and willpower.org have their on-premise enterprise Identity Management Solutions running with Identity Server.
Both these organizations use cloud services offered by WSO2 StratosLive and have created tenants in there.
Now, they want to provision the user account, identity management operations such as creating/deleting users and groups, updating user identity attributes etc which happens in their on-premise Identity Server to the respective tenants they have in StratosLive, as shown in the above diagram.
Implementation:
In this case, Identity Server running inside the organizational boundaries of each organization act as SCIM consumers and the Identity Server as a Service running in StratosLive acts as a SCIM Service Provider.
Each organization can register SCIM provider configurations pointing to their tenant space in SLive, within enterprise IS instances.
Following is a step by step guide for this.
Step1: setup
Download and unzip IS distribution into three different folders (to represent instances at: 1.wso2, 2.willpower, 3.SLive)
Increment Ports->PortOffset element in carbon.xml s.t three instances are running in following ports:
IS of WSO2: 9443
IS of Willpower: 9444
SLive IS: 9445
You can find more details on how to do this step from the step1 of my previous post.
Step 2: creating tenants
Login as admin to the IS instance that simulates Stratos IS in our setup and create two tenants named "wso2.com" and "willpower.com".
Screen shots of the steps shown below:
Step3: registering SCIM providers
Now login to IS instances of WSO2 and WillPower organizations as admin user and register SCIM provider configurations pointing to their respective tenant spaces in SLive IS instance.
For a more detailed guide on how to register SCIM providers, please refer to step3 of my previous post.
Example configurations shown below:
Step 4: testing provisioning
Now you can test creating/deleting/updating users, groups in organizational IS instances and verify that they are provisioned to particular tenant space of each organization in SLive IS instance.
That's it... Thanks..!
"Today the enterprise IT solutions adopt products and services from multiple cloud providers in order to accomplish various business requirements. Hence it is no longer sufficient to maintain user identities only in corporate LDAP.
Identity Server(IS) 4.0.0 which is a 100% open source Enterprise Identity & Entitlement Management Server, supports the open standard SCIM for identity provisioning as I have mentioned in my previous posts as well.
With this, WSO2 Stratos Live next release will also be supporting SCIM for Identity Provisioning.
This post is about implementing a use case of identity provisioning from on-premise to cloud using Identity Server and Stratos (here, same IS distribution can be used to simulate Stratos IS with multi-tenancy aspects).
Following diagram gives an overview of the deployment:
Two organizations called wso2.com and willpower.org have their on-premise enterprise Identity Management Solutions running with Identity Server.
Both these organizations use cloud services offered by WSO2 StratosLive and have created tenants in there.
Now, they want to provision the user account, identity management operations such as creating/deleting users and groups, updating user identity attributes etc which happens in their on-premise Identity Server to the respective tenants they have in StratosLive, as shown in the above diagram.
Implementation:
In this case, Identity Server running inside the organizational boundaries of each organization act as SCIM consumers and the Identity Server as a Service running in StratosLive acts as a SCIM Service Provider.
Each organization can register SCIM provider configurations pointing to their tenant space in SLive, within enterprise IS instances.
Following is a step by step guide for this.
Step1: setup
Download and unzip IS distribution into three different folders (to represent instances at: 1.wso2, 2.willpower, 3.SLive)
Increment Ports->PortOffset element in carbon.xml s.t three instances are running in following ports:
IS of WSO2: 9443
IS of Willpower: 9444
SLive IS: 9445
You can find more details on how to do this step from the step1 of my previous post.
Step 2: creating tenants
Login as admin to the IS instance that simulates Stratos IS in our setup and create two tenants named "wso2.com" and "willpower.com".
Screen shots of the steps shown below:
Step3: registering SCIM providers
Now login to IS instances of WSO2 and WillPower organizations as admin user and register SCIM provider configurations pointing to their respective tenant spaces in SLive IS instance.
For a more detailed guide on how to register SCIM providers, please refer to step3 of my previous post.
Example configurations shown below:
Step 4: testing provisioning
Now you can test creating/deleting/updating users, groups in organizational IS instances and verify that they are provisioned to particular tenant space of each organization in SLive IS instance.
That's it... Thanks..!
Saturday, November 3, 2012
Identity Synchronization across Multiple Nodes with SCIM
We sometimes manage user identities in multiple nodes and we need to synchronize all the nodes when one node gets updated.
In this post we will look at how we can leverage SCIM - an open standard for identity provisioning, to achieve this requirement of Identity Synchronization.
As I have mentioned in my previous post, WSO2 Identity Server (IS) supports identity provisioning with SCIM, based on WSO2 Charon which is the implementation of the specification.
Identity Server can act as both SCIM Consumer and Service Provider.
To achieve the aforementioned requirement, we leverage both those capabilities of IS at once.
Let me describe a use case and then provides steps how to implement that with WSO2 Identity Server.
Use Case:
Lets say we have an organization which has multiple stores distributed across a region. Each store maintains a user store. And there is a central store as well. When one sub store updates its user accounts, that update should be propagated to central node and the central node sends that update to all the other sub stores.
If an update happens in the central node, that should also be propagated to all the sub stores.
Following diagram depicts this better: The directions that each node's updates propagate, are indicated by arrows with specific colour of each node.
Aside each node, I have listed a list of 'Provisioning Admins' along with their provider, if they have any.
Let me describe it. We send a provisioning request to a SCIM provider node from a consumer node. Therefore, we need to register providers at the nodes which plays the role of a consumer at a particular time.
And you need to have an account in the provider node, with proper permission to do provisioning. Because, as I mentioned in the previous post, SCIM Service Provider authenticates and authorizes your provisioning request and fulfils it only it is authenticated and authorized.
Lets implement the above scenario step by step so that you will have a better idea:
Step 1: Setting up three nodes..
Download Identity Server 4.0.0 and unzip it into three folders named: 'store1', 'central', 'store2'.
Since we are starting in the same machine, we need to change the port of set of each IS instance.
Go to [IS_Home]/repository/conf and open carbon.xml. In 'central' instance, make Ports->OffSet to 1 and in 'store2' instance, make Ports->OffSet to2.
Start the three instances.
Now our three instances are running in following ports.
store1: 9443
central: 9444
store2: 9445
Step 2: Registering Provisioning Administrators...
Lets now create user accounts in each node which has privileges to register SCIM providers and/or perform provisioning on behalf of each store, as listed in the above image.
Store1:
Got to management console of store1 IS instance by typing url: https://localhost:9443/carbon/ in a browser, login to management console as admin,admin and go to configure-> users and roles
Create 'centraladmin', 'store2admin' user accounts.
Also create a role called 'provisioning admin' and assign that role the above two users and the two permissions: 'login' and 'Identity Provisioning' as shown in the following diagram.
Now, centraladmin user has the permission to provision user account updates happen in central store, to store1. In this case, central store becomes a SCIM Consumer and store1 becomes a SCIM Service Provider.
And store2admin user has the permission to send provisioning requests to store 1, via central store in order to propagate updates happen in store 2.
Default admin account of store1, which has all the permission, provision the updates happen in store1, to central store.
In this way, please create the relevant provisioning admin user accounts in central store and store2 IS instances as well, as illustrated in the first diagram above and assign them to the provisioning admin role with the two permissions.
Step3: Registering Providers
Identity Server allows consumer nodes to register SCIM providers in two ways:
1. Registering global providers - any user management operation performed in a particular tenant space will be provisioned to the global providers.
2. Registering providers specific to particular user account - any user management operation comes through SCIM Service Provider endpoints of a particular node will be further provisioned to the providers registered under the account from which SCIM requests was authenticated and authorized.
Lets look at how to register SCIM Providers at the central store in our scenario so that both above mechanisms will be clear to you.
1. Registering global SCIM providers at the central store.
According to our requirement, any user management operation performed by users in the admin role of central store should be provisioned to store1 and store2.
- Login as default admin user in central node (https://localhost:9444/carbon/admin/login.jsp)
- Access Main->Manage->SCIM
- Register New SCIM Provider.
We need to register both store1 and store 2 as global providers.
Following image shows the configuration of store1 SCIM provider.
Here we need to define a provier id, and provide user name and password to authenticated and authorized to SCIM provider node(in this case it is centraladmin account which we registered in both store1 ans store2 in the previous step) and the URLs of the SCIM User & Group endpoints.
You need to register store2 also as a global provider with relevant configuration.
2. Registering SCIM providers specific to user accounts, at the central store.
According to our requirement, any provisioning request coming to central store from store1 should be provisioned to all the other sub stores except to store1.
Therefore, user account of the store1admin in the central store should be able to define to which providers my scim provisioning request should be further provisioned to, from the central node.
- Login to central node as store1admin.
- Access Main -> My Identity -> My SCIM Providers
- Now as the store1admin, you can register store2 as the SCIM Provider by providing relevant configuration as shown below.
- And then login to central node as the store2admin account and register SCIM provider pointing to store1 endpoints.
Now we are done configuring central node for our provisioning scenario.
Then login to store1 and store2 IS instances as default admin and register central node as the global provider in both store1 and store2 as shown below.
Store1:
Store2:
Please refer the very first image in this post to make sure that you have created all the relevant provisioning admin user accounts in each IS node, given them proper permission and registered the corresponding SCIM providers as listed in that diagram for each node.
Step 4: Test Identity Synchronization
Now login to store1 as default admin and create a user account. Observe the logs at the backend console of each node. You will observe info logs mentioning that the user created at store1 is also created at central store and store2.
You can login to management console of central store and store2 and verify that the user created in store1 is listed in other two nodes as well.
You can perform other user and role management operations as well in each node and verify whether it is synchronized with other nodes as expected in our use case.
Following are the list of user management operations currently supported in WSO2 Identity Server to be provisioned via SCIM.
1. Create User
2. Delete User
3. Update credential of the user by admin
4. Update the profile of a user by admin
5. Update the profile of a user by the user himself
6. Create Group
7. Delete Group
8. Add users to group by updating group (Update user list of role)
9. Rename Group
Following are the list of user management operations allowed by WSO2 Identity Server, but not currently supported to be provisioned via SCIM.
1. Update credential of the user by user himself.
2. Add users to group by updating user (Update role list of user) - same outcome can be achieved by the no. 8 operation above.
I hope now it is clear to you how we can leverage SCIM - open standard for Identity Provisioning to achieve a use case of Identity Synchronization across multiple nodes using the capabilities of WSO2 Identity Server.
Configuring provisioning through configuration file
Identity Server also supports configuring SCIM providers through configuration file, in addition to allowing to register providers through UI which was explained above.
In this case, it is the admin of a particular node who configure providers which is different to individual provisioning admins registering SCIM providers through UI.
The relevant configuration file is: [IS_Home]/repository/conf/provisioning-config.xml
If you are configuring through configuration file, you need to follow the above steps until step 2 is completed.
Then shut down all the three IS instances. Replace provisioning-config.xml file of each instance with the ones shown below and restart the IS instances.
store1 configuration file:
In this post we will look at how we can leverage SCIM - an open standard for identity provisioning, to achieve this requirement of Identity Synchronization.
As I have mentioned in my previous post, WSO2 Identity Server (IS) supports identity provisioning with SCIM, based on WSO2 Charon which is the implementation of the specification.
Identity Server can act as both SCIM Consumer and Service Provider.
To achieve the aforementioned requirement, we leverage both those capabilities of IS at once.
Let me describe a use case and then provides steps how to implement that with WSO2 Identity Server.
Use Case:
Lets say we have an organization which has multiple stores distributed across a region. Each store maintains a user store. And there is a central store as well. When one sub store updates its user accounts, that update should be propagated to central node and the central node sends that update to all the other sub stores.
If an update happens in the central node, that should also be propagated to all the sub stores.
Following diagram depicts this better: The directions that each node's updates propagate, are indicated by arrows with specific colour of each node.
Aside each node, I have listed a list of 'Provisioning Admins' along with their provider, if they have any.
Let me describe it. We send a provisioning request to a SCIM provider node from a consumer node. Therefore, we need to register providers at the nodes which plays the role of a consumer at a particular time.
And you need to have an account in the provider node, with proper permission to do provisioning. Because, as I mentioned in the previous post, SCIM Service Provider authenticates and authorizes your provisioning request and fulfils it only it is authenticated and authorized.
Lets implement the above scenario step by step so that you will have a better idea:
Step 1: Setting up three nodes..
Download Identity Server 4.0.0 and unzip it into three folders named: 'store1', 'central', 'store2'.
Since we are starting in the same machine, we need to change the port of set of each IS instance.
Go to [IS_Home]/repository/conf and open carbon.xml. In 'central' instance, make Ports->OffSet to 1 and in 'store2' instance, make Ports->OffSet to2.
Start the three instances.
Now our three instances are running in following ports.
store1: 9443
central: 9444
store2: 9445
Step 2: Registering Provisioning Administrators...
Lets now create user accounts in each node which has privileges to register SCIM providers and/or perform provisioning on behalf of each store, as listed in the above image.
Store1:
Got to management console of store1 IS instance by typing url: https://localhost:9443/carbon/ in a browser, login to management console as admin,admin and go to configure-> users and roles
Create 'centraladmin', 'store2admin' user accounts.
Also create a role called 'provisioning admin' and assign that role the above two users and the two permissions: 'login' and 'Identity Provisioning' as shown in the following diagram.
Now, centraladmin user has the permission to provision user account updates happen in central store, to store1. In this case, central store becomes a SCIM Consumer and store1 becomes a SCIM Service Provider.
And store2admin user has the permission to send provisioning requests to store 1, via central store in order to propagate updates happen in store 2.
Default admin account of store1, which has all the permission, provision the updates happen in store1, to central store.
In this way, please create the relevant provisioning admin user accounts in central store and store2 IS instances as well, as illustrated in the first diagram above and assign them to the provisioning admin role with the two permissions.
Step3: Registering Providers
Identity Server allows consumer nodes to register SCIM providers in two ways:
1. Registering global providers - any user management operation performed in a particular tenant space will be provisioned to the global providers.
2. Registering providers specific to particular user account - any user management operation comes through SCIM Service Provider endpoints of a particular node will be further provisioned to the providers registered under the account from which SCIM requests was authenticated and authorized.
Lets look at how to register SCIM Providers at the central store in our scenario so that both above mechanisms will be clear to you.
1. Registering global SCIM providers at the central store.
According to our requirement, any user management operation performed by users in the admin role of central store should be provisioned to store1 and store2.
- Login as default admin user in central node (https://localhost:9444/carbon/admin/login.jsp)
- Access Main->Manage->SCIM
We need to register both store1 and store 2 as global providers.
Following image shows the configuration of store1 SCIM provider.
Here we need to define a provier id, and provide user name and password to authenticated and authorized to SCIM provider node(in this case it is centraladmin account which we registered in both store1 ans store2 in the previous step) and the URLs of the SCIM User & Group endpoints.
You need to register store2 also as a global provider with relevant configuration.
2. Registering SCIM providers specific to user accounts, at the central store.
According to our requirement, any provisioning request coming to central store from store1 should be provisioned to all the other sub stores except to store1.
Therefore, user account of the store1admin in the central store should be able to define to which providers my scim provisioning request should be further provisioned to, from the central node.
- Login to central node as store1admin.
- Access Main -> My Identity -> My SCIM Providers
- And then login to central node as the store2admin account and register SCIM provider pointing to store1 endpoints.
Now we are done configuring central node for our provisioning scenario.
Then login to store1 and store2 IS instances as default admin and register central node as the global provider in both store1 and store2 as shown below.
Store1:
Store2:
Please refer the very first image in this post to make sure that you have created all the relevant provisioning admin user accounts in each IS node, given them proper permission and registered the corresponding SCIM providers as listed in that diagram for each node.
Step 4: Test Identity Synchronization
Now login to store1 as default admin and create a user account. Observe the logs at the backend console of each node. You will observe info logs mentioning that the user created at store1 is also created at central store and store2.
You can login to management console of central store and store2 and verify that the user created in store1 is listed in other two nodes as well.
You can perform other user and role management operations as well in each node and verify whether it is synchronized with other nodes as expected in our use case.
Following are the list of user management operations currently supported in WSO2 Identity Server to be provisioned via SCIM.
1. Create User
2. Delete User
3. Update credential of the user by admin
4. Update the profile of a user by admin
5. Update the profile of a user by the user himself
6. Create Group
7. Delete Group
8. Add users to group by updating group (Update user list of role)
9. Rename Group
Following are the list of user management operations allowed by WSO2 Identity Server, but not currently supported to be provisioned via SCIM.
1. Update credential of the user by user himself.
2. Add users to group by updating user (Update role list of user) - same outcome can be achieved by the no. 8 operation above.
I hope now it is clear to you how we can leverage SCIM - open standard for Identity Provisioning to achieve a use case of Identity Synchronization across multiple nodes using the capabilities of WSO2 Identity Server.
Configuring provisioning through configuration file
Identity Server also supports configuring SCIM providers through configuration file, in addition to allowing to register providers through UI which was explained above.
In this case, it is the admin of a particular node who configure providers which is different to individual provisioning admins registering SCIM providers through UI.
The relevant configuration file is: [IS_Home]/repository/conf/provisioning-config.xml
If you are configuring through configuration file, you need to follow the above steps until step 2 is completed.
Then shut down all the three IS instances. Replace provisioning-config.xml file of each instance with the ones shown below and restart the IS instances.
store1 configuration file:
central store configuration file:store1admin store1admin https://localhost:9444/wso2/scim/Users https://localhost:9444/wso2/scim/Groups
store2 configuration file:centraladmin centraladmin https://localhost:9443/wso2/scim/Users https://localhost:9443/wso2/scim/Groups centraladmin centraladmin https://localhost:9445/wso2/scim/Users https://localhost:9445/wso2/scim/Groups
store2admin store2admin https://localhost:9444/wso2/scim/Users https://localhost:9444/wso2/scim/Groups
WSO2 Identity Server as a SCIM Service Provider
As I have blogged in my previous posts, we have developped WSO2 Charon as an open source implementation of SCIM protocol which is an open standard for Identity Provisioning.
It can be used by any one who wants to add SCIM based provisioning support for their applications.
We have integrated WSO2 Charon with WSO2 Identity Server 4.0.0which is available to be downloaded at http://wso2.com/products/identity-server/
In this post, I am going to demonstrate how to utilize its SCIM endpoints which expose User and Group resources in Restful way.
Following is a high level overview of SCIM Service Provider architecture of IS.
For simplicity, I will use curl commands to send CRUD requests to the rest endpoints of Identity Server.
Download Identity Server from above link, unzip it and start...
URL of the SCIM User Endpoint is: https://localhost:9443/wso2/scim/Users
URL of the SCIM Group Endpoint is: https://localhost:9443/wso2/scim/Groups
These endpoints are exposed over https since sensitive information is exchanged and also protected with Basic Auth Authentication.
Create User:
curl -v -k --user admin:admin --data "{"schemas":[],"name":{"familyName":"gunasinghe","givenName":"hasinitg"},"userName":"hasinitg","password":"hasinitg","emails":[{"primary":true,"value":"hasini_home.com","type":"home"},{"value":"hasini_work.com","type":"work"}]}" --header "Content-Type:application/json" https://localhost:9443/wso2/scim/Users
Here we authenticate with Basic Auth and send the payload in JSON format adhering to the SCIM 1.1 specification.
You will get a response with 201 CREATED status and pay load as below:
{"id":"48f7cfe5-f0e3-4a67-af7e-d762aa9ab215","schemas":["urn:scim:schemas:core:1.0"],"name":{"familyName":"gunasinghe","givenName":"hasinitg"},"userName":"hasinitg","emails":[{"value":"hasini_home.com","type":"home"},{"value":"hasini_work.com","type":"work"}],"meta":{"lastModified":"2012-11-03T18:36:53","location":"https://localhost:9443/wso2/scim/Users/48f7cfe5-f0e3-4a67-af7e-d762aa9ab215","created":"2012-11-03T18:36:53"}}
There, you will notice that it contains some additional attributes such as unique id, created, last modified and location which are READ ONLY attributes and set by the service provider.
Now access the management console of Identity Server in a browse with URL:
https://localhost:9443/carbon/admin/login.jsp and login as admin with credential admin.
You will notice that the above created user is shown under:
You can access user profile of the user and see first name and last name are set properly but not other fields. That is because default claims of Carbon uses a different set of attributes in LDAP than the SCIM specific dialect (will discuss about it in detail later).
But those attributes are stored in the underlying user store. You can verify that by going a GET request on the User.
GET User:
You can retrieve a particular user resource using its unique id:
curl -v -k --user admin:admin https://localhost:9443/wso2/scim/Users/48f7cfe5-f0e3-4a67-af7e-d762aa9ab215
You will notice that all the attributes that were sent are there in the response as well.
List Users:
Now create some users through the web management console of Identity Server and fill in their profile details. I created two users called Umesha and Shyama and filled in their profile details.
curl -v -k --user admin:admin https://localhost:9443/wso2/scim/Users
Response:
{"schemas":["urn:scim:schemas:core:1.0"],
"totalResults":3,
"Resources":
[
{"id":"48f7cfe5-f0e3-4a67-af7e-d762aa9ab215","name": {"familyName":"gunasinghe","givenName":"hasinitg"},"userName":"hasinitg","emails":[{"value":"hasini_work.com","type":"work"},{"value":"hasini_home.com","type":"home"}],"meta":{"lastModified":"2012-11-03T18:36:53","created":"2012-11-03T18:36:53","location":"https://localhost:9443/wso2/scim/Users/48f7cfe5-f0e3-4a67-af7e-d762aa9ab215"}},
{"id":"8dd71de9-e2f9-47b7-a5d4-a5f3862950ff","profileUrl":"shyama@blogspot.com","ims":["gmail"],"roles":["everyone"],"name":{"familyName":"shyama","givenName":"Shyama"},"userName":"shyama","emails":["shyama@example.com"],"phoneNumbers":[{"value":"7890","type":"mobile"}],"addresses":[{"value":"Panadura","type":"streetAddress"},{"value":"Sri Lanka","type":"country"}],"meta":{"lastModified":"2012-11-03T18:53:46","created":"2012-11-03T18:52:41"}},
{"id":"6b14c23d-4811-4bbd-b653-04fcda2df266","profileUrl":"umesha@blogspot.com","ims":["gmail"],"roles":["everyone"],"name":{"familyName":"umesha","givenName":"Umesha"},"userName":"umesha","emails":["umesha@gmail.com"],"phoneNumbers":[{"value":"857657","type":"mobile"}],"addresses":[{"value":"Pannipitiya","type":"streetAddress"},{"value":"Sri Lanka","type":"country"}],"meta":{"lastModified":"2012-11-03T18:51:52","created":"2012-11-03T18:50:26"}}
]
}
You can see the three users representation with attributes in JSON format adhering to SCIM Schema.
Update User:
I am going to update the work and home email of user: hasinitg through following curl command:
Note: you have to use the correct SCIM ID by taking it either from create user response or from list user response.
curl -v -k --user admin:admin -X PUT -d "{"schemas":[],"name":{"familyName":"gunasinghe","givenName":"hasinitg"},"userName":"hasinitg","emails":[{"value":"hasini@wso2.com","type":"work"},{"value":"hasi7786@gmail.com","type":"home"}]}" --header "Content-Type:application/json" https://localhost:9443/wso2/scim/Users/48f7cfe5-f0e3-4a67-af7e-d762aa9ab215
You will get a response with 200 OK response and a payload containing the updated user representation.
Delete User:
Now I will delete the user with userName 'shyama' which was created through management console of IS:
curl -v -k --user admin:admin -X DELETE https://localhost:9443/wso2/scim/Users/8dd71de9-e2f9-47b7-a5d4-a5f3862950ff -H "Accept: application/json"
You will get a response with status 200 OK and the user will be deleted from the user store.
In the same way, we can manage groups by performing CRUD operations on the Group resource endpoint.
Filter User:
Since CRUD operations have to be performed using SCIM ID which is unique to Service Provider, User REST endpoint also supports filter operation. You can filter users with userName which is considered as the unique user attribute in Carbon servers.
curl -v -k --user admin:admin https://localhost:9443/wso2/scim/Users?filter=userNameEqumesha
You will get a response like below from which you can extract the SCIM ID to perform rest of the operations.
{"schemas":["urn:scim:schemas:core:1.0"],"totalResults":1,"Resources":[{"id":"6b14c23d-4811-4bbd-b653-04fcda2df266","profileUrl":"umesha@blogspot.com","ims":["gmail"],"roles":["everyone"],"name":{"familyName":"umesha","givenName":"Umesha"},"userName":"umesha","emails":["umesha@gmail.com"],"phoneNumbers":[{"value":"857657","type":"mobile"}],"addresses":[{"value":"Pannipitiya","type":"streetAddress"},{"value":"Sri Lanka","type":"country"}],"meta":{"lastModified":"2012-11-03T18:51:52","created":"2012-11-03T18:50:26"}}]}
Create Group:
You can create groups either with or without members.
Following command creates a group with a user.
Note: when creating a group with users, you need to have that user already existing in the user store and provide its unique id. So lets create a new group named: 'engineer' with user 'umesha' as a member.
curl -v -k --user admin:admin --data "{"displayName": "engineer","members": [{"value":"6b14c23d-4811-4bbd-b653-04fcda2df266","display": "umesha"}]}" --header "Content-Type:application/json" https://localhost:9443/wso2/scim/Groups
You will get a response with payload like below and a response status 201 CREATED:
{"id":"e8868723-30b2-4979-ae23-6d1de2e7d841","schemas":["urn:scim:schemas:core:1.0"],"displayName":"engineer","members":[{"value":"6b14c23d-4811-4bbd-b653-04fcda2df266","display":"umesha"}],"meta":{"lastModified":"2012-11-03T20:33:16","created":"2012-11-03T20:33:16","location":"https://localhost:9443/wso2/scim/Groups/e8868723-30b2-4979-ae23-6d1de2e7d841"}}
You can observe in the management console of IS, that the new group is listed under roles and user Umesha is listed under users of that group.
List Groups:
Now lets create another role through IS management console and list all the groups. Create a group named: 'manager' without any users added to it.
Now list the groups: You can see both groups are listed.
{"schemas":["urn:scim:schemas:core:1.0"],
"totalResults":2,"Resources":[
{"id":"e8868723-30b2-4979-ae23-6d1de2e7d841","displayName":"engineer","members":[{"value":"6b14c23d-4811-4bbd-b653-04fcda2df266","display":"umesha"}],"meta":{"lastModified":"2012-11-03T20:33:16","created":"2012-11-03T20:33:16","location":"https://localhost:9443/wso2/scim/Groups/e8868723-30b2-4979-ae23-6d1de2e7d841"}},
{"id":"3f26902e-c22b-48bc-ba0a-c197a5710b70","displayName":"manager","meta":{"lastModified":"2012-11-03T20:39:25","created":"2012-11-03T20:39:25","location":"https://localhost:9443/wso2/scim/Groups3f26902e-c22b-48bc-ba0a-c197a5710b70"}}
]}
Update Group:
Now lets rename the group 'manager' to executive:
curl -v -k --user admin:admin -X PUT -d "{"displayName": "executive"}" --header "Content-Type:application/json" https://localhost:9443/wso2/scim/Groups/3f26902e-c22b-48bc-ba0a-c197a5710b70
You will get a response with 200 OK status and full JSON representation of the updated group.
Delete Group:
You can delete the group using the unique SCIM Id of the group. Following command will delete the group: 'executive'
curl -v -k --user admin:admin -X DELETE https://localhost:9443/wso2/scim/Groups/3f26902e-c22b-48bc-ba0a-c197a5710b70 -H "Accept: application/json"
Filter Group:
You can filter groups with the group display name. Following command will filter the group with display name: 'engineer'
curl -v -k --user admin:admin https://localhost:9443/wso2/scim/Groups?filter=displayNameEqengineer
Response:
{"schemas":["urn:scim:schemas:core:1.0",null],"totalResults":1,"Resources":[{"id":"e8868723-30b2-4979-ae23-6d1de2e7d841","displayName":"engineer","members":[{"value":"6b14c23d-4811-4bbd-b653-04fcda2df266","display":"umesha"}],"meta":{"lastModified":"2012-11-03T20:33:16","created":"2012-11-03T20:33:16","location":"https://localhost:9443/wso2/scim/Groups/e8868723-30b2-4979-ae23-6d1de2e7d841"}}]}
It can be used by any one who wants to add SCIM based provisioning support for their applications.
We have integrated WSO2 Charon with WSO2 Identity Server 4.0.0which is available to be downloaded at http://wso2.com/products/identity-server/
In this post, I am going to demonstrate how to utilize its SCIM endpoints which expose User and Group resources in Restful way.
Following is a high level overview of SCIM Service Provider architecture of IS.
Download Identity Server from above link, unzip it and start...
URL of the SCIM User Endpoint is: https://localhost:9443/wso2/scim/Users
URL of the SCIM Group Endpoint is: https://localhost:9443/wso2/scim/Groups
These endpoints are exposed over https since sensitive information is exchanged and also protected with Basic Auth Authentication.
Create User:
curl -v -k --user admin:admin --data "{"schemas":[],"name":{"familyName":"gunasinghe","givenName":"hasinitg"},"userName":"hasinitg","password":"hasinitg","emails":[{"primary":true,"value":"hasini_home.com","type":"home"},{"value":"hasini_work.com","type":"work"}]}" --header "Content-Type:application/json" https://localhost:9443/wso2/scim/Users
Here we authenticate with Basic Auth and send the payload in JSON format adhering to the SCIM 1.1 specification.
You will get a response with 201 CREATED status and pay load as below:
{"id":"48f7cfe5-f0e3-4a67-af7e-d762aa9ab215","schemas":["urn:scim:schemas:core:1.0"],"name":{"familyName":"gunasinghe","givenName":"hasinitg"},"userName":"hasinitg","emails":[{"value":"hasini_home.com","type":"home"},{"value":"hasini_work.com","type":"work"}],"meta":{"lastModified":"2012-11-03T18:36:53","location":"https://localhost:9443/wso2/scim/Users/48f7cfe5-f0e3-4a67-af7e-d762aa9ab215","created":"2012-11-03T18:36:53"}}
There, you will notice that it contains some additional attributes such as unique id, created, last modified and location which are READ ONLY attributes and set by the service provider.
Now access the management console of Identity Server in a browse with URL:
https://localhost:9443/carbon/admin/login.jsp and login as admin with credential admin.
You will notice that the above created user is shown under:
| Configure | > Users and Roles | > Users |
You can access user profile of the user and see first name and last name are set properly but not other fields. That is because default claims of Carbon uses a different set of attributes in LDAP than the SCIM specific dialect (will discuss about it in detail later).
But those attributes are stored in the underlying user store. You can verify that by going a GET request on the User.
GET User:
You can retrieve a particular user resource using its unique id:
curl -v -k --user admin:admin https://localhost:9443/wso2/scim/Users/48f7cfe5-f0e3-4a67-af7e-d762aa9ab215
You will notice that all the attributes that were sent are there in the response as well.
List Users:
Now create some users through the web management console of Identity Server and fill in their profile details. I created two users called Umesha and Shyama and filled in their profile details.
curl -v -k --user admin:admin https://localhost:9443/wso2/scim/Users
Response:
{"schemas":["urn:scim:schemas:core:1.0"],
"totalResults":3,
"Resources":
[
{"id":"48f7cfe5-f0e3-4a67-af7e-d762aa9ab215","name": {"familyName":"gunasinghe","givenName":"hasinitg"},"userName":"hasinitg","emails":[{"value":"hasini_work.com","type":"work"},{"value":"hasini_home.com","type":"home"}],"meta":{"lastModified":"2012-11-03T18:36:53","created":"2012-11-03T18:36:53","location":"https://localhost:9443/wso2/scim/Users/48f7cfe5-f0e3-4a67-af7e-d762aa9ab215"}},
{"id":"8dd71de9-e2f9-47b7-a5d4-a5f3862950ff","profileUrl":"shyama@blogspot.com","ims":["gmail"],"roles":["everyone"],"name":{"familyName":"shyama","givenName":"Shyama"},"userName":"shyama","emails":["shyama@example.com"],"phoneNumbers":[{"value":"7890","type":"mobile"}],"addresses":[{"value":"Panadura","type":"streetAddress"},{"value":"Sri Lanka","type":"country"}],"meta":{"lastModified":"2012-11-03T18:53:46","created":"2012-11-03T18:52:41"}},
{"id":"6b14c23d-4811-4bbd-b653-04fcda2df266","profileUrl":"umesha@blogspot.com","ims":["gmail"],"roles":["everyone"],"name":{"familyName":"umesha","givenName":"Umesha"},"userName":"umesha","emails":["umesha@gmail.com"],"phoneNumbers":[{"value":"857657","type":"mobile"}],"addresses":[{"value":"Pannipitiya","type":"streetAddress"},{"value":"Sri Lanka","type":"country"}],"meta":{"lastModified":"2012-11-03T18:51:52","created":"2012-11-03T18:50:26"}}
]
}
You can see the three users representation with attributes in JSON format adhering to SCIM Schema.
Update User:
I am going to update the work and home email of user: hasinitg through following curl command:
Note: you have to use the correct SCIM ID by taking it either from create user response or from list user response.
curl -v -k --user admin:admin -X PUT -d "{"schemas":[],"name":{"familyName":"gunasinghe","givenName":"hasinitg"},"userName":"hasinitg","emails":[{"value":"hasini@wso2.com","type":"work"},{"value":"hasi7786@gmail.com","type":"home"}]}" --header "Content-Type:application/json" https://localhost:9443/wso2/scim/Users/48f7cfe5-f0e3-4a67-af7e-d762aa9ab215
You will get a response with 200 OK response and a payload containing the updated user representation.
Delete User:
Now I will delete the user with userName 'shyama' which was created through management console of IS:
curl -v -k --user admin:admin -X DELETE https://localhost:9443/wso2/scim/Users/8dd71de9-e2f9-47b7-a5d4-a5f3862950ff -H "Accept: application/json"
You will get a response with status 200 OK and the user will be deleted from the user store.
In the same way, we can manage groups by performing CRUD operations on the Group resource endpoint.
Filter User:
Since CRUD operations have to be performed using SCIM ID which is unique to Service Provider, User REST endpoint also supports filter operation. You can filter users with userName which is considered as the unique user attribute in Carbon servers.
curl -v -k --user admin:admin https://localhost:9443/wso2/scim/Users?filter=userNameEqumesha
You will get a response like below from which you can extract the SCIM ID to perform rest of the operations.
{"schemas":["urn:scim:schemas:core:1.0"],"totalResults":1,"Resources":[{"id":"6b14c23d-4811-4bbd-b653-04fcda2df266","profileUrl":"umesha@blogspot.com","ims":["gmail"],"roles":["everyone"],"name":{"familyName":"umesha","givenName":"Umesha"},"userName":"umesha","emails":["umesha@gmail.com"],"phoneNumbers":[{"value":"857657","type":"mobile"}],"addresses":[{"value":"Pannipitiya","type":"streetAddress"},{"value":"Sri Lanka","type":"country"}],"meta":{"lastModified":"2012-11-03T18:51:52","created":"2012-11-03T18:50:26"}}]}
Create Group:
You can create groups either with or without members.
Following command creates a group with a user.
Note: when creating a group with users, you need to have that user already existing in the user store and provide its unique id. So lets create a new group named: 'engineer' with user 'umesha' as a member.
curl -v -k --user admin:admin --data "{"displayName": "engineer","members": [{"value":"6b14c23d-4811-4bbd-b653-04fcda2df266","display": "umesha"}]}" --header "Content-Type:application/json" https://localhost:9443/wso2/scim/Groups
You will get a response with payload like below and a response status 201 CREATED:
{"id":"e8868723-30b2-4979-ae23-6d1de2e7d841","schemas":["urn:scim:schemas:core:1.0"],"displayName":"engineer","members":[{"value":"6b14c23d-4811-4bbd-b653-04fcda2df266","display":"umesha"}],"meta":{"lastModified":"2012-11-03T20:33:16","created":"2012-11-03T20:33:16","location":"https://localhost:9443/wso2/scim/Groups/e8868723-30b2-4979-ae23-6d1de2e7d841"}}
You can observe in the management console of IS, that the new group is listed under roles and user Umesha is listed under users of that group.
List Groups:
Now lets create another role through IS management console and list all the groups. Create a group named: 'manager' without any users added to it.
Now list the groups: You can see both groups are listed.
{"schemas":["urn:scim:schemas:core:1.0"],
"totalResults":2,"Resources":[
{"id":"e8868723-30b2-4979-ae23-6d1de2e7d841","displayName":"engineer","members":[{"value":"6b14c23d-4811-4bbd-b653-04fcda2df266","display":"umesha"}],"meta":{"lastModified":"2012-11-03T20:33:16","created":"2012-11-03T20:33:16","location":"https://localhost:9443/wso2/scim/Groups/e8868723-30b2-4979-ae23-6d1de2e7d841"}},
{"id":"3f26902e-c22b-48bc-ba0a-c197a5710b70","displayName":"manager","meta":{"lastModified":"2012-11-03T20:39:25","created":"2012-11-03T20:39:25","location":"https://localhost:9443/wso2/scim/Groups3f26902e-c22b-48bc-ba0a-c197a5710b70"}}
]}
Update Group:
Now lets rename the group 'manager' to executive:
curl -v -k --user admin:admin -X PUT -d "{"displayName": "executive"}" --header "Content-Type:application/json" https://localhost:9443/wso2/scim/Groups/3f26902e-c22b-48bc-ba0a-c197a5710b70
You will get a response with 200 OK status and full JSON representation of the updated group.
Delete Group:
You can delete the group using the unique SCIM Id of the group. Following command will delete the group: 'executive'
curl -v -k --user admin:admin -X DELETE https://localhost:9443/wso2/scim/Groups/3f26902e-c22b-48bc-ba0a-c197a5710b70 -H "Accept: application/json"
Filter Group:
You can filter groups with the group display name. Following command will filter the group with display name: 'engineer'
curl -v -k --user admin:admin https://localhost:9443/wso2/scim/Groups?filter=displayNameEqengineer
Response:
{"schemas":["urn:scim:schemas:core:1.0",null],"totalResults":1,"Resources":[{"id":"e8868723-30b2-4979-ae23-6d1de2e7d841","displayName":"engineer","members":[{"value":"6b14c23d-4811-4bbd-b653-04fcda2df266","display":"umesha"}],"meta":{"lastModified":"2012-11-03T20:33:16","created":"2012-11-03T20:33:16","location":"https://localhost:9443/wso2/scim/Groups/e8868723-30b2-4979-ae23-6d1de2e7d841"}}]}
Friday, March 30, 2012
SCIM Interop Event at IETF 83rd Meeting
First interop event organized by SCIM working group (or originally named as Cloud Directory WG), was held in the room: Corot of hotel Concorde La Fayette, Paris on 28th of March from 6-12 CET.
Purpose: The purpose of this event was to bring together current working implementations of SCIM and test the level of interoperability between each other which in turn could be used as a valuable input to prove the interoperability of the SCIM spec itself for the Birds of Feathers Session that was held on 29th of March, in order to form a SCIM working group in IETF.
Participants:
Erik & Samuel from Technology Nexus,
Kelly from Sailpoint,
Chuck from Salesforce,
Trey from UnboundID,
Travis from Ping Identity,
Morteza from Cisco,
Emmanuel from BCPSOFT,
Hasini from WSO2,
participated in person while Michael from Gluu and James from Curion, participated remotely.
Following are some pics I took during the interop event:
Rest of the post is mainly about the interop experiences of WSO2 Charon when it was tested against SCIM service providers and SCIM Clients provided by other implementations.
WSO2 Charon:
Charon is the open source SCIM implementation offered by WSO2 under Apache 2.0 license. You may refer to my previous blog posts to get an idea about WSO2 Charon. Milestone 1 of WSO2 Charon was released in the time for first interop event. You may refer to a nice blog post written by Prabath on M1 release of Charon. We hosted a public SCIM endpoint for interop testing at people.wso2.com.
At the start of the interop event, Every one shared their server credentials with participants and started testing by picking one endpoint at a time and sending requests from their clients.
WSO2 Charon SCIM Client was tested against the SCIM endpoints provided by following SCIM service provider implementations:
- Technology Nexus
- UnboundID
- Curion
- Salesforce
- Ping Identity
This list doesn't contain all in the participants list above, since Sailpoint offers only a SCIM Client implementation and other service provider endpoints were busy with fixing some of the issues encountered during the interop event.
Varying level of successes achieved when Charon client tested with each of the above endpoints among which highest percentage of success was achieved with Unbound Identity(8 out of 10 scenarios passed) and Technology Nexus(6 out of 10 scenarios passed) endpoints.
WSO2 Charon-Samples module includes sample SCIM clients which cover all the SCIM operations supported by Charon as of its M1 release. These sample SCIM client programs made it easy to cover all the other working SCIM server endpoints during the 6 hours time period of the interop event.
Interop issues found: Following are some of the issues found when testing WSO2 Charon client with other server endpoints which caused some operations to fail. We negotiated and discussed about how to align the implementations with the spec in order to overcome those issues.
2. Server returns an error when read-only attributes are contained in the payload of an update request. According to the spec: "Consumers must retrieve the entire Resource and PUT the desired modifications as the operation overwrites all previously stored data." The example payloads in the spec also contains read-only "id" attribute in the update request. Therefore, we agreed that spec needs more clarifications whether it should fail or ignore the read-only attributes in the update request payload and update only other attributes.
3. Server had an internal requirement to include a group attribute when creating a user and if a group is not provided, create user operation fails. But according to the spec, group attribute in User resource is read-only. Therefore, we agreed that servers should not mandate to expect group attribute in create User request payload, even if they have internal server requirements to do so.
4. Server replies with dateTime attributes formatted in .NET DateTime strings. WSO2 Charon client expects date time attributes be formatted in XML Schema Datatypes Specification (2008-01-23T04:56:22Z) which is mentioned in SCIM spec. Agreed to follow the same format for dateTime as specified in SCIM spec in order to avoid interop issues even on these minor areas.
5. Server doesn't add an id attribute rather considers external ID as the id of the resource. Still it is not made mandatory to make it unique which may cause issues in retrieving a particular resource.
Other SCIM Clients were tested against WSO2 Charon SCIM service provider endpoints:
- Curion
- Technology Nexus
Note: WSO2 Charon endpoint is available for public access and you may carry out interop testing with it anytime and please let us know if you find any issues.
Interop issues found: Following is the only issue reported by the ones who tested against WSO2 Charon endpoint:
1. List user operation returning "resource not found" error.
This operation returns proper response with the list of resources like below, when List user operation is performed with WSO2 Charon client. :
{
"schemas":["urn:scim:schemas:core:1.0"],
"totalResults":2,
"Resources":
[
{
"id":"0f6fd995-38fb-4240-a5ce-961a7032427f",
"externalId":"umesha",
"meta"{
"lastModified":"2012-03-28T05:56:32",
"created":"2012-03-28T05:56:32",
"location":"http://localhost:8080/charonDemoApp/scim/Users/0f6fd995-38fb-4240-a5ce-961a7032427f"
}
},
{
"id":"e942ac6d-476c-4c7a-add3-f4ecb068a2f6",
"externalId":"hasini@gmail.com",
"meta":{
"lastModified":"2012-03-28T05:53:27",
"created":"2012-03-28T05:53:27",
"location":"http://localhost:8080/charonDemoApp/scim/Users/e942ac6d-476c-4c7a-add3-f4ecb068a2f6"
}
}
]
}
But due to an interop issue when the same was performed with other clients, it shows an unexpected behavior which needs to be reproduced and identified with that particular client.Overall Comments:
I consider the whole interop event was an effective session where we were able to discuss and agree on interpretation of certain points of the spec wrt implementation aspects and identify areas of the spec which needs more clarification in order to overcome some of the interop issues mentioned above.
It was also a good community meetup where the people who are communicating remotely over the mailing list could get together and meet in person and make their implementations communicate with each other.
I would like to Thank all participants for collaborating effectively during the session to make the interop event a success.
WSO2 Charon road map in brief:
WSO2 Charon will be feature completed with its 1.0 release and will be integrated into WSO2 Identity Server 4.0.0 so that WSO2 product stack and WSO2 Stratos will be equipped with the standardized identity provisioning feacture based on SCIM.
Monday, March 5, 2012
Implementing SCIM with WSO2 Charon - Part III
In this post, lets look at how to implement few use cases of SCIM with WSO2 Charon.
You may need to refer to my previous posts on SCIM and Charon to get an overview of them.
Being the third post on Charon, lets continue looking at it in the top down approach.
This post will demonstrate the following capabilities of Charon according to SCIM spec.
1). Create user
2). Create group
3). List Users
Download CharonDemoApp from M1 Distribution and deploy it in an application server like Apache Tomcat and start the server.
As shown in the diagram of the part-II post, User Resource and Group Resource are now exposed based on Apache Wink JAX-RS implementation, via following URLS.
1. Creating a user..
This demonstrates how a SCIM consumer creates (provision) a User in SCIM service provider via a REST call in which User attributes are carried as a JSON encoded string.
Client code : SCIM client uses the previously registered credentials to authenticate the request.
- service provider responds with 201-Created response code and
- includes newly created user in response body.
- Representation in response contains an additional attributes 'id', 'created date', 'last modified date' etc which is assigned by the SP and
- the "Location" header contains the unique URI of the created user resource.
2. Create Group..(From SCIM spec)
Server responds with 200 OK including group resource in the body encoded in JSON.
3. List Users
Following request/response illustrates a SCIM consumer call to list all the users.
Server responds with two user entries existing in its user store.
You can find the required libraries to run the WSO2 Charon samples from here.
2. Sample source code can be found in the M1 distribution linked above.
You may need to refer to my previous posts on SCIM and Charon to get an overview of them.
Being the third post on Charon, lets continue looking at it in the top down approach.
Part II described the composition of Charon-Impl. which is the SCIM service provider reference implementation shipped with Charon. It is a Apache Wink based webapp that utilizes Charon-Core and Charon-Utils to expose a SCIM REST API for identity provisioning operations.
This post will demonstrate the following capabilities of Charon according to SCIM spec.
1). Create user
2). Create group
3). List Users
Setting up SCIM Service Provider with Charon-Impl:
Download CharonDemoApp from M1 Distribution and deploy it in an application server like Apache Tomcat and start the server.
As shown in the diagram of the part-II post, User Resource and Group Resource are now exposed based on Apache Wink JAX-RS implementation, via following URLS.
- User Resource: http://localhost:8080/charonDemoApp/scim/Users
- Group Resource: http://localhost:8080/charonDemoApp/scim/Groups
1. Creating a user..
This demonstrates how a SCIM consumer creates (provision) a User in SCIM service provider via a REST call in which User attributes are carried as a JSON encoded string.
Client code : SCIM client uses the previously registered credentials to authenticate the request.
package org.wso2.charon.samples.user.sample01;
import org.apache.wink.client.ClientConfig;
import org.apache.wink.client.ClientWebException;
import org.apache.wink.client.Resource;
import org.apache.wink.client.RestClient;
import org.apache.wink.client.handlers.ClientHandler;
import org.wso2.charon.core.client.SCIMClient;
import org.wso2.charon.core.exceptions.CharonException;
import org.wso2.charon.core.objects.User;
import org.wso2.charon.core.schema.SCIMConstants;
import org.wso2.charon.samples.utils.CharonResponseHandler;
import org.wso2.charon.samples.utils.SampleConstants;
import org.wso2.charon.utils.authentication.BasicAuthHandler;
import org.wso2.charon.utils.authentication.BasicAuthInfo;
public class CreateUserSample {
//user details
public static final String USER_NAME = "hasinig";
public static final String EXTERNAL_ID = "hasini@gmail.com";
public static final String[] EMAILS = {"hasini@gmail.com", "hasini@wso2.com"};
public static final String DISPLAY_NAME = "Hasini Gunasinghe";
public static final String PASSWORD = "dummyPW";
public static final String LANGUAGE = "Sinhala";
public static final String PHONE_NUMBER = "9077657623";
public static void main(String[] args) {
try {
//create SCIM client
SCIMClient scimClient = new SCIMClient();
//create a user according to SCIM User Schema
User scimUser = scimClient.createUser();
scimUser.setUserName(USER_NAME);
scimUser.setExternalId(EXTERNAL_ID);
scimUser.setEmails(EMAILS);
scimUser.setDisplayName(DISPLAY_NAME);
scimUser.setPassword(PASSWORD);
scimUser.setPreferredLanguage(LANGUAGE);
scimUser.setPhoneNumber(PHONE_NUMBER, null, false);
//encode the user in JSON format
String encodedUser = scimClient.encodeSCIMObject(scimUser, SCIMConstants.JSON);
//create a apache wink ClientHandler to intercept and identify response messages
CharonResponseHandler responseHandler = new CharonResponseHandler();
responseHandler.setSCIMClient(scimClient);
//set the handler in wink client config
ClientConfig clientConfig = new ClientConfig();
clientConfig.handlers(new ClientHandler[]{responseHandler});
//create a wink rest client with the above config
RestClient restClient = new RestClient(clientConfig);
//create resource endpoint to access User resource
Resource userResource = restClient.resource(SampleConstants.USER_ENDPOINT);
BasicAuthInfo basicAuthInfo = new BasicAuthInfo();
basicAuthInfo.setUserName(SampleConstants.CRED_USER_NAME);
basicAuthInfo.setPassword(SampleConstants.CRED_PASSWORD);
BasicAuthHandler basicAuthHandler = new BasicAuthHandler();
BasicAuthInfo encodedBasicAuthInfo = (BasicAuthInfo) basicAuthHandler.getAuthenticationToken(basicAuthInfo);
//TODO:enable, disable SSL. For the demo purpose, we make the calls over http
//send previously registered SCIM consumer credentials in http headers.
String response = userResource.
header(SCIMConstants.AUTHORIZATION_HEADER, encodedBasicAuthInfo.getAuthorizationHeader()).
contentType(SCIMConstants.APPLICATION_JSON).accept(SCIMConstants.APPLICATION_JSON).
post(String.class, encodedUser);
//decode the response
System.out.println(response);
} catch (CharonException e) {
e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
} catch (ClientWebException e) {
System.out.println(e.getRequest().getEntity());
System.out.println(e.getResponse().getMessage());
e.printStackTrace();
}
}
}
Request-Response: Please click on the below image to see it in full size. After successful creation of the user;- service provider responds with 201-Created response code and
- includes newly created user in response body.
- Representation in response contains an additional attributes 'id', 'created date', 'last modified date' etc which is assigned by the SP and
- the "Location" header contains the unique URI of the created user resource.
2. Create Group..(From SCIM spec)
Following request/reponse is captured when creating a group with two exisiing users in the system.
Request-Response: Please click on the below image to see it in full size.Server responds with 200 OK including group resource in the body encoded in JSON.
Following request/response illustrates a SCIM consumer call to list all the users.
Server responds with two user entries existing in its user store.
Note:
1. Libraries for sample client code:You can find the required libraries to run the WSO2 Charon samples from here.
2. Sample source code can be found in the M1 distribution linked above.
3. As illustrated by above sample use case, SCIM consumer will be able to perform identity provisioning operations with any SCIM service provider in a unified way by just changing the resource URLs - which avoids the need of developping multiple connectors to integrate with different cloud providers.
Tuesday, February 14, 2012
Implementing SCIM with Charon - Part II
We had a look at an overview of WSO2 Charon in my previous post.
Today lets go through a brief introduction of the module : Charon-Deplyment, which is the reference implementation of SCIM service provider that is shipped with Charon.
This will illustrate how any concrete implementation of a SCIM service provider can make use of Charon-Core (the SCIM API) with Charon-Utils (optional). So being the second post on Charon, this will continue the top down approach of looking at it.
As we got to know from the introductory post on SCIM, the protocol defines a REST API for user identity provisioning operations.
Hence SCIM service provider needs to be a RESTful web application. In an earlier post, I have noted down the characteristic of REST - which is an architectural style of building networked applications.
There are several ways to implement a REST style based applications - such as Servlets and JAX-RS based frameworks.
In the reference implementation of Charon-SCIM servervice provider, we have selected the latter approach since JAX-RS hides underlying HTTP handling and binds the servlets nicely to individual methods in the Java classes using annotations. Annotations can also dynamically extract information from HTTP requests and map application-generated exceptions to HTTP response codes.
There are several ways to implement a REST style based applications - such as Servlets and JAX-RS based frameworks.
In the reference implementation of Charon-SCIM servervice provider, we have selected the latter approach since JAX-RS hides underlying HTTP handling and binds the servlets nicely to individual methods in the Java classes using annotations. Annotations can also dynamically extract information from HTTP requests and map application-generated exceptions to HTTP response codes.
Out of the JAX-RS implementations, Apache-Wink was selected since it looks promising to cater our requirements.
The Charon-Impl module creates an Apache-Wink based web application which can be deployed in an application server like Tomcat and which acts as a SCIM service provider.
Following is a deployment diagram of Charon-SCIM service provider (the web application provided by Charon-Impl module). It also gives a high level idea on how Charon-Core and Charon-Utils modules will be utilized.
As this diagram of the reference implementation illustrates, a SCIM service provider can be developed using any REST implementation and SCIM-defined resources can be exposed utilizing the API provided by Charon-Core.
On the other hand, SCIM Consumers can also be implemented using the client API of Charon-Core.
More posts to be followed...
Sunday, February 12, 2012
Implementing SCIM with Charon - Part 1
You may need to refer to my previous blog post in order to get an overall idea on SCIM - Simple Cloud Identity Management..
This is about WSO2 Charon - one of the SCIM implementations which will be made available under Apache 2.0 license. Lets look at it in a top down approach.
Following diagram will give an overview on the module break down of Charon along with purpose of each module and planned tasks of them.
Following is a brief introduction on each of the modules:
Well.. this is a brief overview of what Charon is, how it is structured and what each module is supposed to do, supposed to be used for.
More posts on Charon to be followed...
This is about WSO2 Charon - one of the SCIM implementations which will be made available under Apache 2.0 license. Lets look at it in a top down approach.
Following diagram will give an overview on the module break down of Charon along with purpose of each module and planned tasks of them.
Following is a brief introduction on each of the modules:
- Charon-Core:
This is the API that exposes an implementation of SCIM specification. It can be used by any SCIM service provider or client implementation to support SCIM operations/functionalities. In addition to that, it also allows room for extension points to be plugged in according to the particular server side/client side implementation, such as authentication handler, user storage, encoders/decoders etc.
- Charon-Utils:
- Charon-Deployment: (Note: this is renamed as Charon-Impl)
A reference implementation of SCIM service provider will be shipped with this module. Currently it is a Apache Wink based webapp that can be deployed in any application server - such as Tomcat, and make the SCIM endpoints be exposed. This is based on the above two modules : charon-core and charon-utils, and illustrates how any SCIM implementation can utilize the API and supporting module provided by Charon.
- Charon-Samples:
Well.. this is a brief overview of what Charon is, how it is structured and what each module is supposed to do, supposed to be used for.
More posts on Charon to be followed...
SCIM - To overcome identity provisioning nightmares...
Identity provisioning is a key aspect of any Identity Management Solution.
In simple terms, it is to create, maintain and delete user accounts and related identities in one or more systems or applications in response to business processes which are initiated either by humans directly or by automated tasks.
In simple terms, it is to create, maintain and delete user accounts and related identities in one or more systems or applications in response to business processes which are initiated either by humans directly or by automated tasks.
Today the enterprise solutions adopt products and services from multiple cloud providers in order to accomplish various business requirements. Hence it is no longer sufficient to maintain user identities only in corporate LDAP.
In most cases, SaaS providers also need dedicated user accounts created for the cloud service users, which raises the need of proper identity provisioning mechanisms to be in place.
In most cases, SaaS providers also need dedicated user accounts created for the cloud service users, which raises the need of proper identity provisioning mechanisms to be in place.
Currently, different cloud vendors expose non-standard provisioning APIs which makes it a nightmare for the enterprises to develop and maintain proprietary connectors to integrate with multiple SaaS providers.
For an example, Google exposes Google Provisioning API for provisioning user accounts in Google Apps Domain.
When enterprise IT systems consist of distributed, heterogeneous components from multiple vendors and from both in house and from cloud, it is key to have an open standard that all agree upon, in order to achieve interoperability and simplicity while getting rid of multiple connectors to perform the same thing.
Simple Cloud Identity Management is an emerging open standard which defines a comprehensive REST API along with a platform neutral schema and a SAML binding to facilitate the user management operations across SaaS applications; placing specific emphasis on simplicity and interoperability as well.
SCIM specification is in its version 1 and the cloud directory working group is working on submitting it to IETF. You can get subscribed to cloud-directory@googlegroups.com and get updated with the latest happenings w.r.t SCIM spec.
Following embedded presentation which was used in a webinar, illustrates how some of the common use cases encountered in an enterprise identity management solution are achieved with SCIM.
We also identify the key characteristics of SCIM which makes it preferable over the other existing provisioning standards. Highlights of the overall SCIM specification -which is currently consisted of three normative parts, is also included in the slides.
We also identify the key characteristics of SCIM which makes it preferable over the other existing provisioning standards. Highlights of the overall SCIM specification -which is currently consisted of three normative parts, is also included in the slides.
Subscribe to:
Posts (Atom)