U.S. patent application number 13/873165 was filed with the patent office on 2013-09-26 for multi-domain identity interoperability and compliance verification.
The applicant listed for this patent is Lakshmanan Kannappan, Hemma Prafullchandra, Vijay S. Simha. Invention is credited to Lakshmanan Kannappan, Hemma Prafullchandra, Vijay S. Simha.
Application Number | 20130254882 13/873165 |
Document ID | / |
Family ID | 40304937 |
Filed Date | 2013-09-26 |
United States Patent
Application |
20130254882 |
Kind Code |
A1 |
Kannappan; Lakshmanan ; et
al. |
September 26, 2013 |
MULTI-DOMAIN IDENTITY INTEROPERABILITY AND COMPLIANCE
VERIFICATION
Abstract
An identity management deployment, interoperability, and
compliance verification is discussed. In one embodiment, the system
also provides on-demand services including automated certification,
monitoring, alerting, routing, and translation of tokens for
federated identity related interactions between multi-domain
identity management systems is provided.
Inventors: |
Kannappan; Lakshmanan;
(Sunnyvale, CA) ; Simha; Vijay S.; (Sunnyvale,
CA) ; Prafullchandra; Hemma; (Mountain View,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Kannappan; Lakshmanan
Simha; Vijay S.
Prafullchandra; Hemma |
Sunnyvale
Sunnyvale
Mountain View |
CA
CA
CA |
US
US
US |
|
|
Family ID: |
40304937 |
Appl. No.: |
13/873165 |
Filed: |
April 29, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12185809 |
Aug 4, 2008 |
8434129 |
|
|
13873165 |
|
|
|
|
60953684 |
Aug 2, 2007 |
|
|
|
Current U.S.
Class: |
726/22 |
Current CPC
Class: |
G06Q 30/06 20130101;
G06F 21/64 20130101; G06Q 10/10 20130101; H04L 63/0815
20130101 |
Class at
Publication: |
726/22 |
International
Class: |
G06F 21/64 20060101
G06F021/64 |
Claims
1. A method of providing identity federation deployment comprising:
utilizing a pre-generated schema for generating a deployment system
including interoperability between two or more SP/IDPs; providing a
testing environment to validate that the two or more SP/IDPs are
capable of interoperation at the deployment level; and creating a
customized quality assurance environment to implement at least one
of the SP and IDP, the customized quality assurance environment
used to test deployment validation scenarios.
2. The method of claim 1, wherein the SP is a client, and the SP is
designed to interface with one or more IDPs.
3. The method of claim 1, further comprising: rolling out the
quality assurance environment to a pre-production environment, the
pre-production environment interfacing a SP/IDP with a
pre-deployment version of an SP/IDP.
4. The method of claim 3, wherein the pre-deployment version of the
SP/IDP is a service provider client.
5. The method of claim 3, further comprising: rolling out a
production environment in which a fully deployed version of an SP
interface with a fully deployed version of the IDP; and providing a
tap to monitor communications between the SP and the IDP.
6. The method of claim 5, wherein monitoring communications between
the SP and the IDP comprises: decrypting, parsing, and assembling
an identity-related communication between the SP and the IDP; and
validating the identity-related communication.
7. The method of claim 6, wherein validating the identity-related
communication comprises comparing the communication to a deployment
profile; and generating a validation report.
Description
RELATED APPLICATION
[0001] The present application is a continuation of U.S. patent
application Ser. No. 12/185,809, filed Aug. 4, 2008, now U.S. Pat.
No. 8,434,129, issuing on Apr. 30, 2013, which claims priority to
U.S. Provisional Application Ser. No. 60/953,684 filed on Aug. 2,
2007, which is incorporated herein in its entirety.
FIELD OF THE INVENTION
[0002] The present invention relates to identity, and more
particularly to federated identity management.
BACKGROUND
[0003] Digital Identity is the corner stone for internet security
and is becoming pervasively important with the emergence of
internet businesses and online services offered over the internet.
As a direct consequence of this, many industry verticals like
financial services, government, insurance, healthcare,
pharmaceutical, retail, telecommunication companies and Web 2.0
small businesses are adopting digital identity (hence forth
referred to as identity) technologies in their portfolio of
offerings.
[0004] Identity federation (hence forth referred to as federation)
is an important aspect of identity management solution which
enables businesses to seamlessly exchange user information such as
user name, credentials, attributes, and policy in a secure manner
without compromising the identity and privacy of the user. One of
the biggest problems that identity federation solves is the ability
to provide web users with a true single sign on (SSO) experience
across service providers who are within disparate domains or
infrastructures. While SSO adds great value to the business in
terms of improvements to, or perhaps complete elimination of, the
need for user and password administration and in giving rich user
experience to clients of the business, it does introduce many
challenges in the areas of user privacy and trust between business
partners among others including software as service (Saas)
providers and business process outsourcers (BPOs).
[0005] In the recent years, vendors and customers of identity
management products have been working closely to produce standards
to address many of the challenges of identity federation in a
uniform and non proprietary manner. This effort has led to the
emergence of multiple specifications such as SAML1.1, SAML2.0,
Liberty Alliance ID-WSF, Web Services Standards (WS-*), OpenID,
etc.
SUMMARY OF THE INVENTION
[0006] A method and apparatus to provide identity management
deployment interoperability and compliance verification. In one
embodiment, the system also provides on-demand services including
automated certification, monitoring, alerting, routing, and
translation of tokens for federated identity related interactions
between multi-domain identity management systems is provided.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] The present invention is illustrated by way of example, and
not by way of limitation, in the figures of the accompanying
drawings and in which like reference numerals refer to similar
elements and in which:
[0008] FIG. 1A is an illustration of one embodiment of the overall
vision of this system.
[0009] FIG. 1B shows one embodiment of the identity management
formats for an enterprise.
[0010] FIG. 2 is a block diagram of one embodiment of the MDIS
services.
[0011] FIG. 3 is an illustration of one embodiment of the entities
and protocols involved in a Federation.
[0012] FIG. 4 is an illustration of one embodiment of the various
aspects of federation.
[0013] FIGS. 5A-J are illustrations of various embodiments of
relationships between IDPs and SPs.
[0014] FIG. 6A is a diagram showing one embodiment of staged
deployment and certification configurations.
[0015] FIG. 6B is a diagram showing one embodiment of the stages of
deployment.
[0016] FIG. 7A is a diagram showing one embodiment of an overview
of the MDIS System.
[0017] FIG. 7B is an architecture diagram of one embodiment of the
MDIS system elements.
[0018] FIG. 7C is an overview block diagram of one embodiment of
the MDIS certification framework.
[0019] FIG. 8A is a block diagram of one embodiment of the MDIS
architecture.
[0020] FIG. 8B is a diagram showing one embodiment of a MDIS
solution which simulates the customer's IDM environment as well as
their partner IDM.
[0021] FIG. 9A is a block diagram of one embodiment of the
configured virtual machine and VLAN architecture.
[0022] FIG. 9B illustrates the various VLAN logical architectures
that may be utilized.
[0023] FIG. 10 is an illustration of one embodiment of an MDIS
virtual identity build scenario process.
[0024] FIG. 11 is a process flow diagram of the customer SLA
roll-over process.
[0025] FIG. 12 illustrates an overview flowchart of partner
on-boarding.
[0026] FIG. 13 is a flowchart of one embodiment of the
implementation process.
[0027] FIG. 14 illustrates one embodiment of the federation and web
service life cycle management.
[0028] FIG. 15 is a diagram illustrating one embodiment of
automated federation monitoring.
[0029] FIG. 16 is a block diagram of one embodiment of typical
federation and MDIS services.
[0030] FIG. 17 is a summary of one embodiment of MDIS services.
[0031] FIG. 18 is an exemplary user interface for an MDIS
portal.
[0032] FIG. 19 is an exemplary user interface for a client.
DETAILED DESCRIPTION
[0033] The method and apparatus described is an identity federation
technology that enables the rapid interfacing between identity
management systems operating in accordance with different
standards. Although all the leading vendors of Identity and Access
Management (IAM) products have started to offer standards based
implementations, these specifications fall short when it comes to
actual deployments which include business, policy, compliance and
technology requirements.
[0034] One important aspect of adopting an identity federation
technology is the ability of that technology to not just solve the
SSO problem but how well it can deal with the business criteria of
the enterprise and all of its partners in that industry segment.
The business criteria as it applies to federation, comprises in one
embodiment: business policies, contracts, legal issues,
liabilities, security and privacy policies, technology
interoperability, and similar issues encountered by a business.
Before investing in a particular federation product, it is
absolutely critical for a customer to assess, evaluate, test and
certify the product capabilities as it applies to the comprehensive
business criteria of the enterprise. This also involves evaluating
and testing for interoperability between vendors offering products
based on multiple standards (SAML, WS-*, ID-WSF etc.).
[0035] The challenges that enterprises face in adopting federation
technology is the interoperability issues arising from a disparate
set of business criteria between federating partners. The present
system solves this problem, in one embodiment, by providing one or
more of the following features: [0036] Deployment based
pre-production interoperability; [0037] Compliance verification
services; [0038] Virtual Federated Identity Hub-Spoke hosting
including various scenarios; [0039] Partner Federation
enablement--Deployment services; [0040] Partner Federation
Certification, including Interoperability Testing and Compliance
Verification; [0041] Monitoring, Alerting and on-going Federation
Mgmt services (live mode); [0042] Hosted Federation routing,
translation services.
[0043] These features help enterprises to evaluate and choose a
technology that satisfies critical business criteria and maximizes
return on investment (ROI).
[0044] The present invention is a MDIS (Multi-Domain Identity
Services) platform that offers, in one embodiment, a
deployment/business criterion based hosted certification and
testing services on a "pre-production" or "pilot" basis. The system
provides a quality assurance/verification in a controlled
environment, with controlled and targeted roll-over into a
production environment. In one embodiment, the system may further
provide an ability to pre-qualify partners to ensure that they can
be integrated into the QA/verification environment as well as
support for post-deployment verification of partner federations.
The MDIS platform may further provide additional features. The
location where this deployment takes place can be referred to as a
virtual identity hub. The virtual identity hub includes one or more
virtual IDPs and/or SPs. It is used to simulate a real-world
environment, but is enclosed and fully monitored. The identity
governance addresses the needs of enterprises producing and
consuming identity data to adhere to applicable policies, both
business and legal, such that all parties involved in a federated
identity transactions can manage risk and provide privacy
protection to users. MDIS helps reduce security risks by providing
a pre-production testing and certification environment to such
enterprises.
[0045] FIG. 1A illustrates one embodiment of the overall vision. It
includes a content layer, on top of which there are one or more of
commerce, communication, community, and collaboration
technologies/services. At least some of these aspects may need a
user to be properly identified, i.e. signed on or identity
validated. An identity enabler is used to do this. In one
embodiment, user profiles interact with personalized services, such
as EPIC 1.0 services to provide identity, authentication, identity
profile (e.g. age), and validation information to the applications
and/or the user.
[0046] FIG. 1B shows one embodiment of the identity management
formats for an enterprise. It shows "Stove Pipe" applications with
maintenance, time to market and & service level issues. After
stove-pipe applications, the corporation can move to "internal"
federation for improved internal maintenance, time to market, and
service levels. However, this still restricts the user within the
domain. Finally, the corporation can move to an ecosystem of
enterprises which includes internal and external federation, for
cross-domain sharing of services. This provides improved operations
and cost effectiveness.
[0047] FIG. 2 illustrates one embodiment of MDIS Services which may
be provided. MDIS provide a means to assure the interoperability
and compliance of Identity Provider (IDP) and/or Service Provider
(SP) customers that are interfacing with various identity
management vendor products. Such products may include custom/home
grown and/or open source implementations. The federation, in one
embodiment, is provided in accordance with the Liberty Alliance.
OASIS SAML, WS-Federation, or another appropriate specification. In
some instances, there may also be custom SAML, and open source
federation. However, these federation standards do not ensure that
the communication will meet the business goals and policies of the
customers.
[0048] The federation interoperability and compliance verification
services, provided using the MDIS platform, are designed in one
embodiment to ensure that the federated identity services meet the
business goals and criteria of the customers. In one embodiment,
the services provided may include on-demand hosted services
including automated certification, monitoring, alerting, routing,
and translation of tokens. In one embodiment, MDIS has customer
vertical specific SAML or Web Services security deployment profiles
for which federation certification is automated.
[0049] A deeper look at one embodiment of the federation components
is provided in FIG. 3. This figure provides an exemplary list of
some of the popular vendors, protocols, and components of the MDIS
service.
[0050] In one embodiment, successful federation has various
aspects, as shown in FIG. 4. These aspects range from trust issues,
to regulatory compliance, and business aspects. In order to provide
services to a customer, simply providing federation which enables
communications between the various IAM vendor products is not
optimal. The MDIS platform in one embodiment provides a system in
which all these aspects of federation are considered and verified
for the customer. Using the MDIS process, the system provides
governance and risk mitigation. Furthermore, security risk is
minimized up-front, by ensuring that communications and partners
are certified.
[0051] FIG. 5A-J show some of the configurations that an Identity
Provider (IDP) and a Service Provider (SP) could have. The IDP and
SP interact. In one embodiment, during pre-production
certification, the IDP and/or SP may be implemented within the
secure sandbox of the MDIS environment. Then, once the system is
rolled out into production, in one embodiment the MDIS platform may
maintain taps on the IDP and SP deployments. These taps, in one
embodiment provide the identity data exchanges between the IDP and
the SP to the MDIS platform, enabling the MDIS platform to provide
real-time verification and compliance monitoring.
[0052] In one embodiment, the MDIS system includes an IDP hub, an
SP, and a browser. The browser is part of the MDIS environment and
enables a customer to log into the system. In one embodiment, the
customer connects through a remote desktop, and logs securely into
the portal. FIG. 18 is an exemplary user interface for an MDIS
portal. As can be seen, the portal hub enables management of
deployment profiles, as well as partners, partner certificates,
validation requests, etc.
[0053] In one embodiment, during a certain phase of deployment, the
browser, SP, and/or IDP can be external to MDIS (e.g. use the
deployed browser/SP/IDP).
[0054] In one embodiment these taps are web services interface to
the IDP and SP deployments that enable real-time access to their
respective logs to enable the MDIS platform to provide real-time
health monitoring and correlated audit log access. In one
embodiment, each of the IDPs and SPs in the federation has a tap,
to provide complete data to the MDIS platform. In another
embodiment, the MDIS platform is capable of providing services even
when taps are not available for all SPs and IDPs.
[0055] As shown in FIG. 5A, a single IDP and SP may provide
services to each other. In one embodiment, the multi-domain
services provided by the present system are provided through taps
at both the IDP and SP. The taps, in one embodiment, send copies of
transmissions between the IDP and the SP to a separate secure
storage server, which then provides the MDIS platform.
[0056] As shown in FIG. 5B, an alternative organization of the
system may be a single IDP which provides services to multiple SPs.
This organization is referred to as the hub and spoke model. In one
embodiment, the IDP has a tap and one or more of the SPs also have
a tap. In an alternative model, in which there is a single SP
receiving identity services from a number of different IDPs is
referred to as the community model. This alternative hub and spoke
model is one in which a single SP receives services from multiple
IDPs, as shown in FIG. 5C.
[0057] FIG. 5D is an alternative organization of the system,
involving a consortium model. In this system, various IDPs interact
with various SPs, and vice versa. As noted previously, one or more
of the SPs and IDPs may have taps. In one embodiment, each SP is
coupled to two IDPs, and each IDP provides services to two SPs. In
one embodiment, no SP is coupled to another SP, since SPs cannot
provide services to each other.
[0058] FIG. 5E is an alternative model, referred to as the
delegated or proxy model. The SP sends its request to the first
IDP, which in some instances cannot fulfill the request. In that
case, the first IDP may pass the request on to second IDP which can
provide the identity services requested by the IDP.
[0059] FIG. 5F is an alternative model, referred to as the
intermediary model, in which there is a requesting user, who
contacts an SP or IDP I1, who may pass the request on to one or
more other SPs and/or IDPs. The final SP/IDP in the chain provides
the services back to the requesting user. As noted above, the taps
in each of the SPs and/or IDPs (I1 through I4) provide data on the
flow of the request and response, which is used by the MDIS
platform.
[0060] FIG. 5G is an alternative model, referred to as the peer to
peer governed model. In that model, the central authority receives
requests from one or more SPs, and passes the requests to an IDP
which can fulfill the request.
[0061] FIG. 5H is an alternative model, referred to as the
peer-connected model, in which there is an SP, and numerous IDPs
coupled to the SP and to each other. Unlike the hub and spoke
model, in this model the IDPs also communicate with each other, and
may provide services for each other.
[0062] FIG. 5I is an alternative model referred to as the circles
of trust model. In that model, there are numerous circles of trust.
Each circle of trust can embody one or more of the models described
above with respect to FIGS. 5A-H. However, the IDP(s) in each
circle of trust can, in one embodiment, communicate with other IDPs
in other circles of trust.
[0063] FIG. 5J illustrates three exemplary deployment models,
including exemplary deployments with delegation, and federation
between entities having different business rules, policy and
technology. The MDIS system described in one embodiment is capable
of handling each of these scenarios.
[0064] In each of the above configurations, in one embodiment, in a
pre-production model, the MDIS platform is interposed between each
IDP and SP. This is shown in exemplary embodiments illustrated in
FIGS. 6A and 6B. Once the deployment is complete, and the system is
in use, in one embodiment taps may be used to obtain data about how
the deployment is performing and interoperating. In one embodiment,
taps may be part of each of the IDP and SP implementations. In
another embodiment, only a subset of the IDPs and/or SPs may have
taps. The taps, in one embodiment, enable live managed services and
real-time monitoring, alerting and verification.
[0065] FIG. 6A illustrates staged deployment and certification
configuration. The process includes an MDIS environment, a customer
environment, and partner environments. The process initially starts
out with a virtual IDP and virtual SP. The virtual SP is then
migrated to the customer environment, in one example. In another
example, the virtual IDP is migrated to the customer environment.
The migrated IDP/SP relates to a QA stage SP/IDP. In one
embodiment, the QA stage SP/IDP is in a partner environment.
Finally, the customer IDP moves to a staging environment. At that
point, the federation partner is certified, in one embodiment.
[0066] FIG. 6B is a diagram showing one embodiment of the stages of
deployment. The system is initially deployed entirely within the
MDIS sandbox, with both the SP and the IDP being contained within
the test/certification platform. Once the initial proofing is
finished, either the SP or the IDP is moved from the sandbox to a
pre-production state. This state can provide "live"
testing/certification of the system, but the MDIS sandbox still
hosts the corresponding service (IdP or SP). This is a QA stage,
where full interaction can be simulated.
[0067] At stage 3, both the IDP and the SP are removed from the
sandbox, and moved to actual production state. However, a tap, or
monitor, is inserted into both the IDP and the SP deployment. The
tap or monitor sends the IDP/SP interaction data to the data
scanner in the MDIS. This provides real-time verification in a
post-deployment situation The certification of the moved SP or IDP
is performed against customers' business, compliance, standards,
and/or technology criteria.
[0068] FIG. 6A is a diagram showing one embodiment of message paths
which may be traced. This shows the various phases of deployment.
In the first phase, the customer-partner interoperability scenarios
are deployed in a controlled environment, at least partly at a
controlled facility. A variety of topologies are possible, with
components deployed at the MDIS server, the customer and the
partner.
[0069] A given Pilot Hosting & Testing iteration may involve
several topologies. For example, an initial federation topology
would site both identity provider and service provider at the
server. Successful testing would lead to a second topology of the
identity provider at the server and the service provider at the
partner. In one embodiment, in hosting as well as production, the
same company and even the same server may provide the IDP and SP
functionalities.
[0070] Pilot Hosting & Testing in one embodiment includes at
least some of the following activities: [0071] Protocol
Implementation Test--are the messages being exchanged conformant to
the relevant specifications? [0072] Product-to-Product Testing--do
the selected products successfully interoperate? [0073] Customer
Data Integration--for the federation use case, this might include
business, compliance, and/or technical aspects [0074] Trust
Metadata--does the metadata exchanged between IDP and SP providers
establish the expected trust model and the identity assurance
levels? [0075] Attributes--are the correct data being passed from
the identity provider to the service provider? [0076]
Authentication--is the identity provider authenticating the user
according to the service provider's request? For example, the
service provider might stipulate that access to a particular
function requires smartcard authentication. [0077] Threat
Injection--do the products behave appropriately in the face of
threats such as tampering with signed data, messages outside their
time constraints etc. [0078] Policy-Specific Testing--in a
federation context this might include verifying that, for a given
principal, different name identifiers are generated for each linked
service provider.
[0079] The architectural building blocks that in one embodiment
make up the MDIS platform are shown in FIG. 7A, and listed in the
table below:
TABLE-US-00001 MDIS Component Functionality MDIS Validation Run
time engine to validate federated data agai Engine set of rules
that make up a deployment profile. MDIS Data Component that
intercepts, decrypts, parses an Capture assembles the federation
traffic based on the federation protocol. MDIS Deployment A wealth
of generic and industry segment specif profile library deployment
criteria. MDIS Portal A user interface that allows access to the
MDIS services and user administration services. indicates data
missing or illegible when filed
[0080] FIG. 7A illustrates one embodiment of the high level
extensible architecture of the MDIS platform depicting the various
service offerings:
[0081] In one embodiment, the MDIS platform includes
business/compliance criteria based on-demand services platform
which is Identity and Access Management (IAM) vendor agnostic,
identity protocols agnostic and hence provides a neutral platform
for "pre-production" federation deployment services that extend
beyond product level conformances. In one embodiment, the MDIS
platform offers a library of pre-built deployment profiles that are
both industry segment specific and generic across industry
segments. MDIS platform is designed to work with identity
federation and web services specifications like SAML, ID-WSF,
WS-Federation, WS* and XACML; as well still emerging efforts such
as OpenID 2.0, and OAuth.
[0082] In addition to providing access to pre-built deployment
profiles, in one embodiment, the platform can also be used to
develop and test custom federation scenarios to suit the specific
requirements of a business within a given industry segment.
[0083] The MDIS architecture offers a single unified framework to,
in one embodiment: [0084] Create & manage deployment profiles,
[0085] Configure & test federation scenarios against the
deployment profiles, and [0086] Generate reports based on the
results of the deployment verification testing, highlighting
interoperability issues.
[0087] In one embodiment, the deployment profiles are modeled as
XML based rules that can be processed at runtime by the MDIS
Validation Engine for performing the validation of the actual
federation data against the rules defined in the deployment
profile.
[0088] In one embodiment, the MDIS platform has a Data Capture
component that captures all the identity federation traffic flowing
between an Identity Provider (IDP) and a Service Provider (SP). In
one embodiment, Data Capture component further decrypts the
messages using the associated cryptographic keys, parses the
federation protocol specific messages and feeds it into the MDIS
rules engine for validation.
[0089] In one embodiment, a web portal (hence forth referred to as
MDIS portal) is an interface for businesses to access and interact
with the MDIS federation services. This interface may be used to
set rules, as will be discussed later.
[0090] In one embodiment, the MDIS platform is built on an
extensible architecture that lends itself easily to plug in other
federation services such as compliance management, identity
intermediary and monitoring. In one embodiment, the MDIS
architecture is built to support one or more of the various
federation artifacts such as Trust meta-data, Privacy,
Encryption/Security, and Attribute Data Exchange.
[0091] FIG. 7B is a diagram showing one embodiment of a system in
production. The identity provider and service provider communicate
with each other. The MDIS data capture component receives the data
in the communication stream. In one embodiment, the data is
encrypted, and the data capture component decrypts the data, parses
it, and assembles it. The parsed and assembled data is then passed
to the validation engine.
[0092] The validation engine analyzes the data, using the
deployment profile and determines whether the interaction is
appropriate. In one embodiment, in addition to testing for
validity, the validation engine also ensures compliance with
requirements.
[0093] The results of this validation are stored as validation
reports. Validation reports may be accessed by authorized users
through the MDIS portal.
[0094] FIG. 7C is a diagram of one embodiment of a MDIS Validation
Framework Architecture. As mentioned earlier, the validation
framework is one embodiment of the system which may provide
services. The validation framework is made up of the following
building blocks: [0095] Configuration & Setup module [0096]
Federation Data capture module [0097] Federation Data analysis
module [0098] Report generation module
[0099] FIG. 8A is a block diagram of one embodiment of the
framework elements. The MDIS platform, in one embodiment, is
deployed on a multi-tenant hosting infrastructure (VDC or "Virtual
Data Center"). This allows multiple customer environments to be
hosted in virtualized domains within the managed data center while
ensuring the security and privacy of each customer and their data.
Each customer may utilize one or more environments within the VDC.
The Virtual Data Center allows transparent resource allocation and
workload redistribution across physical servers to optimize the
utilization and availability of physical computing resources
without customers experiencing downtime or delay. In one
embodiment, the MDIS platform is an enterprise-class,
pre-production environment and provides reliability, availability,
service continuity and disaster recovery in one embodiment.
[0100] In one embodiment, the virtual environment includes a domain
name server (DNS). The DNS may be a split DNS. In one embodiment,
the virtual environment may also include a Lightweight Directory
Access Protocol (LDAP) store, an Active Directory, a relational
database, or another store which stores user credential data.
[0101] In one embodiment, the MDIS platform may also be available
as a packaged install for hosting in the customer's data center as
well.
[0102] The MDIS platform, in one embodiment, can provide one-off
integration, a hosted environment supporting testing/certification
and value-added services, and the consumer services platform
addressing future needs of identity protection and user-centric
identity management. There are five components to the platform, in
one embodiment. [0103] Internet Portal [0104] Content and
Configuration Repository [0105] Deployment Sandbox [0106] Adapters
and Libraries [0107] Verification and Testing Tools [0108]
Automated certification, monitoring [0109] Alerting [0110] Routing
[0111] Translation of tokens for federated identity related
interactions between multi-domain IDM systems.
[0112] In one embodiment, the system may further include automated
certification, monitoring, alerting, routing, translation of tokens
for federated identity related interactions between multi-domain
identity management systems.
[0113] The internet portal provides secure remote access to service
providers, partners and vendors. In one embodiment, the secure
access may be provided via SSL VPN and web portal utilizing
role-based access control. Once authenticated, users may access
customizable content (templates, cookbooks, policies,
questionnaires), review progress and run reports against data from
testing and certification activities, and deploy IAM vendor
solutions to their deployment sandbox.
[0114] The configuration repository stores common vendor
configurations and test applications as well as custom
configurations and applications for specific providers. Also
deployed in the sandbox are specially developed adapters and
libraries that enable specific integration or translation scenarios
used in deployment environments. The libraries, for example, may
include a Salesforce.com or .NET integration toolkit.
[0115] FIG. 8B is a block diagram showing one embodiment of an MDIS
solution which simulates the customer's IDM environment as well as
their partner IDM. As can be seen, the MDIS solution provides set
of tools to enable certification of partner federations.
Certification may include, in one embodiment, network monitoring,
capture, correlated logging, auditing and configuration
management.
[0116] FIG. 9A is a block diagram of one embodiment of the
configured virtual machine and VLAN architecture. Effective use of
virtualization technology reduces the hardware and network
resources required to support large number of customers
simultaneously.
[0117] Each customer (typically a hub in a federation network) is
setup as a virtual local area network (VLAN) within MDIS. In one
embodiment, there are many virtual machines within the VLAN. Each
of the virtual machines has appropriate identity management
technologies installed on them. The VLAN network topology is
representative of the federation network of the hub customer both
in terms of network topology (including DNS setup) as well as user
schema elements (generally stored in LDAP or RDBMS).
[0118] A virtual hub is setup for each customer, in one embodiment.
The virtual hub duplicates the customers Identity & Access
Management (IAM) infrastructure as it relates to federation or
web-services security.
[0119] When a customer signs-on to the portal, if this is the first
time, the system will present an option to setup a virtual hub for
the customer. Depending on the role of the customer in a federation
deployment, the system will present options to setup an IdP, SP, or
a virtual hub that can act as both. Next the user is asked to
choose the vendor technology to be used for the creation of the
virtual hub. The vendor technologies are products from vendors such
as CA, IBM, Oracle, Sun, etc. Also, the user is expected to provide
network host DNS names as well as applicable schema to be used for
federation. In the case of web services, this may also include
appliances such as DataPower and provisioning them appropriately
within the MDIS network.
[0120] After choosing the vendor technology, the user in one
embodiment submits the request to the system along with any
additional specific requirements for this customer. The system then
provisions the necessary configuration by performing the
following--
[0121] Create a new VLAN on the Cisco Catalyst Switch. This is done
by looking up at a database and determining which network ports are
available and which are already used. From the unused pool of
network ports, a group of pool of network ports is selected and
allocated to the VLAN.
[0122] This new VLAN is then setup with appropriate network access
rules to limit the access to this network by authorized users. The
VLAN is then added to necessary routing rules within MDIS.
[0123] Next a pre-existing template of the vendor technology
machine is used to instantiate a new virtual machine and added to
this VLAN. If such a template does not exist, then a virtual
machine with only the base O/S is created. The virtual machine is
then populated with the vendor technology. The new virtual is
machine is allocated the necessary hardware resources such as
Memory, CPU power, and hard disk space.
[0124] In one embodiment, every VLAN within MDIS has its DNS server
that is used to setup the requisite network topology. When the
customer logs into the MDIS, split-DNS is used to simulate any
partner network DNS name to test a federation transaction between
the customers' network and simulated host. In one embodiment, the
customer logs in over IP-SEC VPN (virtual private network).
[0125] Once the all the host machines are provisioned in the new
VLAN and the network DNS names have been setup as well as vendor
technology implementation configured, the VLAN is ready for MDIS
validation engine testing and reporting. In one embodiment, an MDIS
engine is installed on one of the machines in the network called
the driver workstation along with its data capture and validation
rules engine routines.
[0126] The MDIS portal interface allows customers access to their
respective scenarios and enables them to execute tests on their
customized scenario. The portal interface also includes in one
embodiment an orchestration engine. The orchestration engine
manages the start/stop of test scenario executions as well as
storing the validation reports for each test run as history.
[0127] In one embodiment, the process is as follows. Upon login the
user is presented with a list of available scenarios. These
scenarios have been created earlier by creating the necessary VLAN
infrastructure as described above.
[0128] The user picks a scenario to be validated and initiates the
process by clicking on a start scenario link. In one embodiment,
this can be done from the browser. In one embodiment the interface
shown in FIG. 24 may be used to initiate this process. This action
by the user sends a message to the orchestration engine to begin a
scenario on the driver workstation.
[0129] The data capture process is started first (this is to ensure
that the initial SSL 3.0/TLS 1.0 handshake between a client and
server is captured to be able to decrypt the secure
communication).
[0130] Next, either a browser instance or a simulated "User-Agent"
is started on the remote driver workstation. The remote
"User-Agent" is controlled by the orchestration engine to interact
with the user on an as-required basis. For e.g. an authentication
prompt at the IdP is captured at the "User-Agent" and relayed to
the end user through the portal interface.
[0131] Once the scenario execution is complete, the user clicks on
a Stop Scenario link which sends a message to the orchestration
engine. The remote "User-Agent" is stopped and the data capture is
also stopped.
[0132] The captured data is then parsed, decoded and decrypted to
extract the message flows on the wire that occurred during the
execution of the scenario. Next, the validation engine is run on
the exchanged messages by applying the applicable validation rules
template for that scenario.
[0133] The output of the validation engine is a Validation Report
that is then stored in the Content Management system along with a
database record. This database record stores the scenario run
details such as--scenario ID, date and time of the run, validation
result file location, etc.
[0134] FIG. 9B illustrates the various VLAN logical architectures
that may be utilized. In one embodiment the system may use
Split-DNS for real-world configuration.
[0135] FIG. 10 illustrates one embodiment of a build scenario
process. The build scenario starts with the physical servers
(server 1 and 2) in this example. In one embodiment, the process
increases capacity by virtualization and sets up virtual servers.
The virtual servers, in one embodiment, may be hosted by one or
more of the actual physical servers. The number of virtual servers
created on a physical server, is only limited by bandwidth and
storage requirements.
[0136] The process then installs scenario building software. In one
embodiment, the scenario building software may include CA, FSS, IBM
TFIM, Oracle Federated Identity Manager, and others. In one
embodiment, the scenario building software may include all IAM
services and federation services corresponding to the services
which were requested by the customer for federation. In some cases,
it could be an open source implementation or simulation of home
grown federated identity implementation.
[0137] The process then configures the software to build the
scenarios. The software is configured to reflect the actual
federation requirements. In one embodiment, the scenarios include
general scenarios (in one embodiment identical across multiple
customer types), vertical specific scenarios (specific to the
market of the customer), and specific scenarios (which are unique
to the particular customer).
[0138] The process then tests the configuration and builds the
actual scenarios. These scenarios built above are tested, verified,
and validated prior to applying them to a QA environment. In this
way, the system provides the ability to integrate existing
scenarios with the customer-specific aspects that ensure that the
customer's resulting IDP or SP meets all of the customer's specific
requirements, as well as more general requirements.
[0139] Once a stable hosted system is deployed, the system may be
used for demonstrations to the customer, partner and third parties.
The output of the Pilot Hosting & Testing phase is a test plan
for verifying that the real-world deployment matches the Deployment
Profile, instructions for moving from the pilot to production
(`customer staging and rollover`) and cookbooks detailing product
configuration, including screenshots where appropriate.
[0140] In one embodiment, the portal interface is run from common
ports shared by all customers. In another embodiment, ports in the
router are assigned to particular customers. In one embodiment, the
port assignment is unique, during the deployment period when the
customer's system is on the platform.
[0141] In one embodiment, the virtualization enables the system to
instantiate each customer when they use are authenticated to log
into the system, or when a query for that customer is received.
This enables the implementation of a large number of customer
systems, while using limited resources. By instantiating the
portal, IDP/SP upon request/log-in, the system can maintain only
those aspects that are currently being utilized by a client.
[0142] In one embodiment, whenever an interaction occurs with the
IDP/SP, a snapshot is created of the system. The snapshot, in one
embodiment, represents the features of the set-up, such that the
particular configuration can be recreated. In one embodiment, the
system maintains a timeline of frozen snapshot. In one embodiment,
a separate snapshot is maintained for each instantiation. In
another embodiment, a separate snapshot is maintained for each
alteration of the set-up. By maintaining snapshots of the system,
if there is a problem, a technician can easily determine what
changes were made between a prior version and the problematic
version. Furthermore, the customer may, in one embodiment,
instantiate any previous version of the system, rather than having
only a current version available for testing.
[0143] FIG. 11 is a detailed chart illustrating one embodiment of
the customer roll-over process.
[0144] When the process is initiated, in one embodiment when a
customer first requests this process, a test environment is set up.
The virtual Identity Hub and testing environment, in one
embodiment, includes a test or virtual IDP and a test or virtual
SP. In one embodiment, the test or virtual IDP/SP (whichever
corresponds to the customer, which can include SP, IDP, or both) is
set up based on a standard profile and specific business profile.
In one embodiment, the process at the test environment stage
includes readiness assessment, standard/business profile
evaluation, and testing of business use cases. The readiness
assessment includes, in one embodiment, evaluating whether the
customer's use cases can be achieved, and whether the customer is
ready to interact with the designated SPs/IDPs. In one embodiment,
if the customer is not federation ready, remediation actions may be
taken to make the customer ready.
[0145] The second stage is setting up a QA environment. In one
embodiment the QA environment may be completely hosted within MDIS.
In an alternative embodiment the QA environment may be hosted at
the customer site. In this example, the SP is designated as the
customer, and the IDP is designated as a partner with which the
customer wishes to interface. It should be clear, however, that
these situations could be reversed, and the IDP may be the
partner.
[0146] In the QA environment, in one embodiment the set up includes
a pre-qualified partner IDP and the customer QA SP. The customer QA
SP is a customer-specific deployment configuration, in one
embodiment. In another embodiment, this may be reversed, and a
pre-qualified partner SP is tested with a customer QA IDP.
[0147] In the QA environment, one or more of the following tests
are taken: technology assessment, determination of customer
specific configuration and application of that configuration to the
customer QA SP, testing for standards compliance, verification of
business profiles, and validation of business use cases.
[0148] Next, the system is rolled to a customer pre-production
environment. In this environment, the set-up includes a partner IDP
and a pre-production version of the customer SP. This environment
is used to perform cross-architecture testing. The environment may
also be used to ensure that there is disaster recovery processes,
that service level agreements (SLAs) and best common practices
(BCPs) are in place. In one embodiment, deployment certification
may also be performed using this set-up.
[0149] Finally, the system is rolled into a production environment.
In the production environment, the customer SP and IDP interact in
a normal fashion. In one embodiment, the MDIS system maintains a
tap on the communications between the IDP and SP. In the production
environment, in one embodiment, the MDIS can continue monitoring to
identify non-compliance, and provide alerting and reporting. In one
embodiment the monitored transactions may be securely archived to
provide audit evidence. In one embodiment, the MDIS may further
provide business process improvements based on observed
interactions. In one embodiment, in addition to monitoring the
customer SP to ensure that it continues to function properly, the
MDIS also uses the data obtained from the production SP and its
interactions as part of a knowledgebase for other partner-customer
deployments, whilst still maintaining privacy.
[0150] In one embodiment, once the system is deployed in a "live
environment" a heartbeat check is still maintained. A heartbeat
check monitors the response of the system to a ping. In one
embodiment, the heartbeat check may be maintained on all live
deployments. In another embodiment, this may be the final phase of
Q&A, in the live environment. The heartbeat monitoring may also
be referred to as proactive monitoring or on-going deployment
verification. By utilizing a heartbeat check, instead of taps, no
customer installation is required. In one embodiment, a tap and a
heartbeat check may be implemented concurrently. In one embodiment,
the live deployment further incorporates an IDS (intrusion
detection system) at the federation level.
[0151] In this way, the system provides a logical deployment
roll-over from initial evaluation through production.
[0152] The pre-production environment is designed to simulate the
"live" production environment. The example described here, the SP
is the customer's SP, while the IDP is a partner IDP. As noted
above, this relationship may be reversed without impacting the
techniques described herein.
[0153] After the initial verification, and Q&A, the SP (or
hub/client) is moved into client's own site. The client still
communicates with the browser or partner behind the same wall,
virtually. The customer accesses the system through a portal. The
customer can interact with sandbox at each of the three positions
(IDP, SP, or browser client) through a portal. Effectively, a
virtual system is created in the portal. The partner, which is a
third party only sees their applicable instance of IdP/SP as
appropriate.
[0154] Once this stage is complete, the next stage is to move the
browser to the local desktop of the client. The hub and the browser
and therefore outside the virtual sandbox. In one embodiment, a
split DNS system is implemented, to ensure all queries are directed
to IDP inside the virtual machine/sandbox. In one embodiment, a tap
system is added to the communication channel between the local
router/firewall and portal. This ensures that even when production
IDPs and SPs are used, the communications can be monitored.
[0155] In one embodiment, the system tests all traffic redirected
to portal as the application is utilized. This enables close
monitoring of the system. In one embodiment, the system further
provides a logging associated with the partner IDP with which the
pre-deployment SP is communicating. This type of correlated logging
is useful to see how communications are received, whether all
messages are properly handled, etc.
[0156] In one embodiment, the system provides partner on-boarding.
FIG. 12 shows an exemplary flowchart of such a process. Once a
particular customer's systems have been validated, further
deployments are much faster. For example, if a hub has 50 partners,
the process can be first used to work with a first spoke. MDIS
provides templates for cookbooks, policy and legal framework
guidelines, deployment best practices and guidelines and
educational materials to speed up on-boarding and certification of
partner federations. FIG. 12 illustrates an overview flowchart of
partner on-boarding. The process starts with qualification, then
moves to interoperation, and certification. The certification is
based on business/compliance/policies/standards/technology criteria
defined by the hub customer in the context of identity federation
with the partner infrastructure. Once a partner is certified, the
system is migrated and tested. This enables speedy addition of
partners.
[0157] When the hub wants to add an additional spoke, the process
of federation will be much faster, since the reusable units created
for the first spoke will be able to be reused. In one embodiment, a
hub can set up a set of steps to move from an initial proof of
concept, pre-qualification of partners, through first deployments,
and then add additional federated environments. In one embodiment,
the addition of further spokes may be set up such that the logical
expansion enables successively more reuse of previously validated
configuration and data. As a 3.sup.rd party support service for
customers, Virtual Identity Hub model of MDIS establishes a
repeatable on-boarding, certification and troubleshooting
environment.
[0158] FIG. 13 is a block diagram of one embodiment of the
implementation process. In one embodiment, the process starts with
creating Validation Criteria document based on Specifications or
Profiles. The validation criteria document, in one embodiment, is a
Word document containing XML markups following a defined validation
criteria schema. The validation criteria are then fed to script
generator to generate one or more test scripts. In one embodiment,
a test script can be directly fed into Validation Engine. A
Validation Engine runs validation scenarios, based on the test
script, and collects data in a test result data file. In one
embodiment, the data is collected in XML format. The test result
data file is fed into a report renderer or viewer to generate human
readable output. In one embodiment, the output is in HTML output
using XSLT transformation. In one embodiment, the report can be
further converted to Word document and/or PDF. The following list
of documents may be involved in a validation process:
[0159] Specifications or profile. These are the validation
requirement documents that define the validation criteria. [0160]
a. Format: In various formats. Most commonly PDF, Word, or HTML.
[0161] b. Audience: Human.
[0162] Validation Criteria. This document defines every aspect of
the validation process--environment, atomic checks, use cases, and
test steps, etc. [0163] a. Format: Word document with attached XML
markups following defined schema. [0164] b. Audience: Human.
[0165] Test Script. This script is automatically generated from
Validation Criteria document and can be provided to validation tool
such as Validation Engine as input. [0166] a. Format: XML [0167] b.
Audience: Machine (Validation Engine)
[0168] Test Result Data. This is an xml document that is
automatically generated by validation tools. The data file contains
references to test script items, however it doesn't contain verbose
text contents. [0169] a. Format: XML [0170] b. Audience: Machine
(For persistence and report viewer)
[0171] Test Report. The test report is generated by report viewer.
Report viewer takes Test Result Data as input, supplement it with
either embedded or referenced text explanation derived from Test
Script and Validation Criteria. This is the final deliverable to
the customer [0172] a. Format: HTML, Word, PDF etc. [0173] b.
Audience: Human.
[0174] FIG. 14 illustrates one embodiment of the federation and web
service life cycle management. As can be seen, the process moves
from pre-production testing, to rapid partner on-boarding during
deployment. Once deployment is complete, the process moves to
operations. During operations, the client's system functions as
normal. However, the system can provide monitoring, incident
tracking, and optimization. In one embodiment, tracking is done
with feeds to a configuration management database (CMDB).
Throughout the process from initial pre-production through
monitoring, a unified management and diagnostic can be delivered to
the customer and the deployment service.
[0175] In one embodiment, the system provides a heartbeat monitor
upon deployment. The heartbeat monitor, in one embodiment, includes
pinging end-points periodically and recording the responses. The
period for pings may be every few minutes/hours/days. In one
embodiment, the ping is every hour during active times, and every 3
hours during non-active times. If the heartbeat ping receives no
response, or an unacceptable response, an alert may be sent. The
system may further generate reports as set up. These reports may
include summary of up-time, usage summaries, etc. The reports may
be automatically generated, as set up by an administrator. The
automatically generated reports may be provided daily, weekly,
and/or monthly. Various administrative contacts may receive reports
at different frequencies.
[0176] FIG. 15 is a diagram of one embodiment of automated
federation monitoring. As can be seen, corporation wishes to
utilize identity services (here SAML 2.0 and web-services
federation, but any other identity management services may be
used), to connect to IdP partners. Corporation connects through
MDIS. MDIS provides a connection to tested and certified partners
through a network. In one embodiment, the MDIS captures and
validates interactions between corporation and partner IDPs. In one
embodiment, MDIS further certifies and monitors the partner IDPs as
well as the interactions. In one embodiment, MDIS further provides
reporting. Reporting, in one embodiment, may be to the
corporation/client.
[0177] FIG. 16 illustrates one configuration showing the typical
federation and MDIS services. The customer logs in through a
portal. FIG. 19 illustrates one embodiment of the portal which may
be used by the client.
[0178] FIG. 19 is an exemplary user interface for a client. In one
embodiment, a user signs into the portal using their login
credentials and a web browser. In one embodiment, the portal
supports federated login, as well as using any input device. Based
on the user identity and associated role, the user has access to
certain functionalities. In one embodiment, as can be seen in FIG.
19, the user may view and add scenarios, partners to qualify. The
system in one embodiment also includes a report indicating the
current status of partners (validated, pending, or failed), and
live (external) partner certification.
[0179] Returning to FIG. 16, The MDIS system includes the portal,
MDIS managed IdP's and/or SPs. The system further may include, in
one embodiment external SPs and IdPs. These external SPs and IdPs
are run, in one embodiment, by unrelated sites, and may be the SPs
and IdPs that would be utilized by the customer during deployment.
In one embodiment, communications between the managed IdPs and SPs
and external IdPs and SPs, and the customer, are monitored and
logged by monitor. In one embodiment, furthermore, the
communications between the managed IdPs and/or SPs and the customer
are fully captured and validated. This enables the system to ensure
that the managed IdPs and SPs perform up to specification.
Furthermore, in one embodiment the monitor and data capture may
remain available after deployment. This would enable the MDIS
services to provide further management after deployment.
[0180] In one embodiment, during set-up of the system, the MDIS
sets up information for the endpoints being monitored (e.g. the
external IdPs and SPs). The system may also be set up with various
types of alters and notifications being sent to designated users.
The designated users, in one embodiment, may be employees of the
deployment service and/or the employees of the client, or both. The
set-up further provides network access, to provide securef
connectivity into the deployment system and the customer system for
monitoring and reporting. In one embodiment, set-up is performed
through a portal hub.
[0181] FIG. 17 illustrates one embodiment of the suite of services
which may be supported by the MDIS platform. The services provide
the ability to assess, interoperate, comply with requirements, and
manage the various aspects of federation.
[0182] Verification and testing tools provide a reusable framework
and value-added tools for common pre-deployment
testing/certification and debugging processes. These tools may
include, for example, token interceptor/inspector, log aggregator,
and tracing/debugging of federation scenarios. Additionally, in one
embodiment, certification and testing tools can test and validate
deployment architecture, including the following functionality:
[0183] identity data federation [0184] data integration [0185]
security, encryption, threat injection, vulnerability testing
[0186] network and DNS topology [0187] scalability, performance,
availability & redundancy (SPAR)
[0188] In one embodiment, additional services related to a
multi-tenant hosted service will also be supported--such as billing
logic and usage tracking.
[0189] A user can access the MDIS over a number of protocols, in
one embodiment. For example, in one embodiment using a web browser,
the user can connect over HTTPS to connect and log into the
customer specific MDIS portal internet address (e.g.
customer.federationportal.com) and view any web accessible content
or services. This includes static and dynamic web content as well
as signed applets. Using a more secure SSL-VPN connection that
requires a client SSL-VPN agent, in one embodiment the user can
connect over other protocols, like SSH and SFTP and also connect
via a web browser to real-world network addresses mirrored inside
of MDIS environment using split-DNS.
[0190] The purpose of using split-DNS is to emulate DNS and network
topology to ensure that the tested environment closely resembles
the real world configuration.
[0191] The MDIS Portal is the entry point for users into the MDIS,
in one embodiment. All user facing interfaces are exposed through
the MDIS, either as web pages in the Portal or specialized protocol
services like SSH and SFTP that are allowed via the Router firewall
rules. In one embodiment, a .NET based SharePoint portal is
utilized.
[0192] Based on the external web address the user entered from
(e.g. customer.federationportal.com), in one embodiment, the user
will be routed to that customer's VLAN for authentication. Once the
user has been authenticated, the user will have access to the
requested customer portal and the hosted scenarios in the customer
Deployment Sandbox.
[0193] In one embodiment, the customer portal runs on a JBoss J2EE
application and portal server and is personalized and branded for
that customer. In one embodiment, the customer portal may be
personalized and branded for the reseller, or service provider.
[0194] The portal, in one embodiment, supports standard portlet
architecture and also enforces Role-Based Access Controls to
control access to actions, scenarios, content and other
repositories within the portal, based on one or more roles
associated with the authenticated user. For example, a partner user
account may only have access to a specific scenario and subset of
content. In one embodiment, content is managed by an embedded
Content Management System (CMS). In an alternative embodiment,
content is managed by an external system. In one embodiment, the
CMS used is Alfresco. In one embodiment, the reports are generated
using Eclipse Foundation's Business Intelligence and Reporting
Tools (BIRT).
[0195] In one embodiment, some users also have access to an
Administration Server for approved administrators to manage and
provision users and perform some portal configuration. In one
embodiment, there is also a Grid Controller for authorized users.
The Grid Controller enables deployment, rebalancing, and management
of scenarios installed for that customer.
[0196] In one embodiment, customers can shutdown and restart their
own scenarios from their portal, but they may not rebalance or
create new scenarios. In one embodiment, the rebalancing and
creating new scenarios is done through a Grid Controller Applet. In
one embodiment, administrators (and resellers in some cases) have
access to the Grid Controller Applet for configuring and deploying
new scenarios. Alternative levels of control may be implemented. In
one embodiment, the administrative set-up may provide role-based
and individual permission-based access and controls.
[0197] In one embodiment, the data is stored in multi-tenant data
repositories. The data repositories store and manage access to a
variety of content. In one embodiment, a number of application
services may be running in the portal that access the repositories.
These include general CMS functionality as well as planning,
reporting, workflow and issue management.
[0198] The primary data repositories include in one embodiment:
[0199] Content--may be Alfresco Content Management System [0200]
Scenario Descriptions--may be Alfresco Content Management System
[0201] Test Plans--may be Alfresco Content Management System [0202]
Test Data and Results--may be Splunk IT Data Search Engine [0203]
Issue Management [0204] Log Data--may be Splunk IT Data Search
Engine
[0205] In one embodiment, the data in the repositories will be
stored in a MySQL database. In one embodiment, some data may be
stored in proprietary formats.
[0206] The Deployment Sandbox is where customer scenarios are
deployed. The sandbox isolates one customer from another and may
contain the entire deployment of the scenario. In one embodiment,
the deployment of a scenario is implemented on a virtual LAN. In
one embodiment, applications are automatically configured as
virtual appliances containing the full operating system and all
software necessary, which are installed and configured correctly on
available hardware. Virtual Appliances in one embodiment may run on
the XEN or VmWare Hypervisor and deployed through the 3Tera
Applogic Grid Operating System. In one embodiment, hardware is
shared and load balanced between multiple VLANS and customer
sandboxes. In another embodiment, hardware is dedicated per
customer sandbox by the Grid Controller. Any specialized hardware
required by the client is, in one embodiment, configured and
deployed within a sandbox.
[0207] The Adapters and Libraries provide the necessary hooks into
the deployed applications, such as virtual appliances and the
Certification and Testing Tools. The adapters, in one embodiment,
also provide hooks into externally hosted infrastructure and
services, (Salesforce.com or a GSA Testing Lab for example).
[0208] The MDIS, in one embodiment, has a plethora of tools and
services for supporting certification and testing. These may
include Data Generators, Protocol Interceptors, Token Inspectors,
Data Collectors, and Threat Injectors. There is also an XML Test
Harness that sets up the necessary tools and services, drives
execution of configured tests against the Deployment Sandbox and
records the results.
[0209] The Virtual Data Center, in one embodiment, is a deployed
instance of the 3Tera Applogic Grid Operating System. The virtual
data center in one embodiment includes a Grid Controller, Global
Volume Store, Virtual Appliance Repository and Assemblies. The Grid
Controller supports configuration, deployment and management of the
Deployment Sandboxes through a web applet. Application binaries and
Data are stored in the Global Volume Store and accessed by the
Grid.
[0210] In the foregoing specification, the invention has been
described with reference to specific exemplary embodiments thereof.
It will, however, be evident that various modifications and changes
may be made thereto without departing from the broader spirit and
scope of the invention as set forth in the appended claims. The
specification and drawings are, accordingly, to be regarded in an
illustrative rather than a restrictive sense.
* * * * *