Documentation
Requirements for building a Connector in
CloudAnywhere
1 INTRODUCTION 3 2 CONNECTOR INSTALLATION 4 3 DEVELOPPING A CONNECTOR 5 3.1 DIRECT CONNECTION 5 3.2 INDIRECT CONNECTIONS 5 4 DEVELOPPING A CONNECTOR 7 4.1 APIREQUIREMENTS 7
4.2 APICRUDOPERATIONS 7
5 EXAMPLE 9
5.1 CREATEUSER 9
5.2 DELETEUSER 9
1
INTRODUCTION
CloudAnywhere is an Identity Management Solution for hosted services. It synchronizes the users, groups, contacts, Organizational Units (OU) and passwords in your source directory (Active Directory, LDAP, etc.) with all your SAAS or ASP suppliers. Connectors are also available to synchronize onpremise LDAP directories.
This software meets the challenges of integrating SAAS applications into your global information system. It helps you to build a business strategy for the Cloud, guaranteeing you control over the administration and access for any present or future SAAS provider.
CloudAnywhere put your Active Directory as the heart of your Cloud strategy by allowing you to manage access to your resources in the Cloud from your local Active Directory.
The Active Directory source may be replaced by any other enterprise source (LDAP, based Google Apps accounts, etc.).
As part of our strategy, we are committed to develop your missing SAAS connectors in order to extend the catalog of targets supported by CloudAnywhere.
CloudAnywhere is shipped with a SDK (Software Development Kit) for creating new connectors to SAAS applications. Thanks to this SDK the CloudAnywhere community regularly develops new connectors and expands the list of suppliers which can be managed by the solution. To set-up a new target, simply move the associated connector into the CloudAnywhere "Connectors" directory.
3
DEVELOPPING A CONNECTOR
3.1
D
IRECTC
ONNECTIONIf the supplier has a SAAS Provisioning API, the connector can communicate natively with the SAAS application and provision it.
Any changes in the source AD (i.e. creation, deletion, modification) of users, groups, contacts or passwords will be pushed in the connected targets.
3.2
I
NDIRECT CONNECTIONS4
DEVELOPPING A CONNECTOR
4.1
API
R
EQUIREMENTSCloudAnywhere synchronized Users, groups, contacts, passwords and Active Directory organizational units between the local Directory and the target provider.
The SAAS provider does not have to provide the methods to manipulate all of these objects, he only has to expose apis for the objects he wants to synchronize.
CloudAnywhere performs CRUD operations. CRUD stands for Create Read Update Delete. Therefore the SAAS provider will need to programmatically expose these operations for all the type of objects he wishes to synchronize. They can expose them through webservices or Rest api.
CloudAnywhere is developed in dotnet C#. If the SAAS application provides libraries that encapusale the calls to its system, it must be in a language that is callable in dotnet. (For example do not provide a java jar library).
4.2
API
CRUD
O
PERATIONSThis chapter explains the methods implemented in a CloudAnywhere connector.
Developing a connector is straightforward. Each of the following methods has to call the corresponding SAAS provider function (if it is implemented).
4.2.1
U
SER OBJECTCloudAnywhere needs to know the naming conventions used by the platform in order to create the unique identifier on the system.
For example, it might be:
The email Address.
A UserName that CloudAnywhere will build dynamically. CloudAnywhere perform the following actions on user objects.
This returns the list of users with additional fields / properties.
4.2.2
C
ONTACT OBJECTSIf the SAAS Platform needs to synchronize contacts, he will have to expose methods similar to the Users object manipulation.
CreateContact, ModifyContact, Delete Contact, ListContacts
4.2.3
G
ROUP OBJECTSActive Directory and LDAP directories uses groups to group users who have similar functionalities (same level of access to an application, member of the same team, etc…). In addition to the notion of group, LDAP directories stores objects in Organizational units. It’s a kind of placeholder where the administrator puts his objects in LDAP.
On the other side, the SAAS provider might also need to group their users and might use a different word to express the same need. He might talk about Groups, roles, entities, etc… CloudAnywhere is flexible and is able to map groups and/or organizational units to the notion of group on the SAAS provider side.
All the provider has to provide is the API to manipulate his groups. CreateGroup
This creates a group and might return a unique identifier. ModifyGroup
This method modifies the properties of a group (ex:description etc…) and the membership.
DeleteGroup
This deletes a uniquely identified group ListGroups
This must return the list of groups and the membership
4.2.4
C
HANGEP
ASSWORDThis function changes the password of a uniquely identified user.
Note: customers might prefer to implement SSO solutions and will not require to synchronize passwords.
The customer will be able to configure CloudAnywhere in order to synchronize or not the passwords with the SAAS provider.
5
EXAMPLE
In the following example, SAASProvider is a class that encapsulates the real apis of the SAAS provider. The CloudAnywhere connector will adapts itself to the requirements of the SAAS provider apis and will pass the required fields to the apis.
5.1
C
REATEU
SERpublic string CreateAccount(List<Shared.Attribute> attributes) {
if (_SAASProvider == null)
throw new Exception("Target " + _ConnectorName + " not initialized");
return _SAASProvider.CreateUser(attributes); }
5.2
D
ELETEU
SERpublic void DeleteAccount(string loginID) {
if (_SAASProvider == null)
throw new Exception("Target " + _ConnectorName + " not initialized");
_SAASProvider.DeleteUser(loginID); }
5.3
C
REATEG
ROUPpublic string CreateGroup(string loginName, string description) {
// Not used by system. Return loginName