Document

advertisement
Documentation
Requirements for building a Connector in
CloudAnywhere
http://www.cloudiway.com
Page 1
Table of Contents
1 INTRODUCTION
3
2 CONNECTOR INSTALLATION
4
3 DEVELOPPING A CONNECTOR
5
3.1 DIRECT CONNECTION
3.2 INDIRECT CONNECTIONS
5
5
4 DEVELOPPING A CONNECTOR
7
4.1 API REQUIREMENTS
4.2 API CRUD OPERATIONS
7
7
5 EXAMPLE
9
5.1 CREATEUSER
5.2 DELETEUSER
5.3 CREATEGROUP
9
9
9
Page 2/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.
This documentation describes the requirements to build a connector.
Page 3/9
2 CONNECTOR INSTALLATION
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.
It will become immediately available.
Page 4/9
3 DEVELOPPING A CONNECTOR
3.1 DIRECT CONNECTION
If 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 INDIRECT CONNECTIONS
If the supplier does not have a SAAS Provisioning API, there are 2 options.
Cloudiway works with the provider to develop the necessary API (see chapter 4).
It might be straightforward to develop and be as simple as developing a webservice that
encapsulates and expose the internal function that manages their accounts database.
As an alternative, (mainly for ASP providers who host Active directories), Cloudiway has
developed a portal that can be installed on the SAAS provider side. CloudAnywhere talks to
this portal which in turn performs the read/write operations to the backend containing the
accounts.
Page 5/9
Page 6/9
4 DEVELOPPING A CONNECTOR
4.1 API REQUIREMENTS
CloudAnywhere 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 OPERATIONS
This 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 USER OBJECT
CloudAnywhere 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.
CreateUser
Input: the mandatory fields used by the SAAS application to create a user (ie: Firstname,
LastName, UserName, Email, etc…)
Return: This call returns a unique identifier (it might be the UserName, email, or a
unique identifier returned by the platform).
If the call doesn’t return an identifier, CloudAnywhere uses the field defined as unique
(username, email, etc…)
ModifyUser
This modifies a uniquely identified users. Changes are passed to the function.
Page 7/9
DeleteUser / SuspendUser
This deletes / Suspends a uniquely identified user.
ListUsers
This returns the list of users with additional fields / properties.
4.2.2 CONTACT OBJECTS
If 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 GROUP OBJECTS
Active 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 CHANGEPASSWORD
This 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.
Page 8/9
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 CREATEUSER
public string CreateAccount(List<Shared.Attribute> attributes)
{
if (_SAASProvider == null)
throw new Exception("Target " + _ConnectorName + " not initialized");
return _SAASProvider.CreateUser(attributes);
}
5.2 DELETEUSER
public void DeleteAccount(string loginID)
{
if (_SAASProvider == null)
throw new Exception("Target " + _ConnectorName + " not initialized");
_SAASProvider.DeleteUser(loginID);
}
5.3 CREATEGROUP
public string CreateGroup(string loginName, string description)
{
// Not used by system.
Return loginName
}
Page 9/9
Download