Patent Application
20160034701
Managing complex online services, including enterprise services, can be a daunting task. For example, a typical enterprise system includes different levels of access based in part on a type of user (e.g., administrators, tenant administrators, end-users, etc.). Assigning access and use permissions for various resources (e.g., files and file systems, email items and systems, directory objects, etc.) is challenging since an assignment depends on what a user needs for a business function, as well as implementation details of any business functions in order to perform desired actions. Licensing enforcement adds an additional layer of complexity due in part to the types of license terms that need to be enforced according to an underlying license or feature, especially as implementation details and arrangements tend to be fluid.
Complex messaging systems can also include system administration, service administration, tenant administration, and self-service administration aspects. System administration may involve deploying and maintaining servers, system configuration tasks, provisioning and maintenance of recipients, etc. Management service administration may involve management actions to run multi-tenant hosted services such as the creation and maintenance of hosted organizations, and interactions with partner services and service upgrades. Tenant administration may involve management actions that hosted organization administrators can perform, such as changing settings of the hosted organization, adding or removing recipients, etc. Self-service administration involves management actions that may be delegated to a user, such as changing a name or address and, creation and maintenance of distribution lists and email subscriptions. However, issues can arise due in part to different approaches to managing the complex service environment, including managing inconsistent policies and security process, duplicity of resources, and an unintended release of or access to restricted information, services, and/or resources as examples.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter.
Embodiments provide control access features, including using a number of validation rules and capabilities of a target as part of proving license control and revenue generating functionalities, but the embodiments are not so limited. In an embodiment, a role-based computing architecture includes the use of feature to command mappings and one or more validation rules to determine if a target of a command has a proper set of capabilities as part of allowing the command to execute. A computing method of one embodiment operates to provide a validation mechanism that performs a validation evaluation as part of a scope check to ensure that a target command is within the command issuer's scope along with a validation rule check for a particular service feature. Other embodiments are included.
These and other features and advantages will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are explanatory only and are not restrictive of the invention as claimed.
In one embodiment, a role-based access control (RBAC) process includes a validation rule check, running in parallel, before, or subsequent to a scope check, including, but not limited to, identifying actions or commands associated with one or more defined features as part of processing a command input and using a feature set to identify capabilities and/or restricted capabilities. For example, components of an RBAC infrastructure can utilize a directory service to examine target objects of a command for a set of capabilities and/or restricted capabilities as part of enforcing one or more license terms.
As part of such an embodiment, an RBAC process includes a validation rule check, running in parallel, before, or subsequent to a scope check, including identifying any validation rule or rule sets associated with a defined feature. For example, a global mailbox feature uses management permissions and associated commands as part of examining capability sets of role-based target objects to determine whether one or more validation rules are applicable to the feature use attempt, and either allowing execution of the action or providing a notice/informative communication. In one embodiment, if the rule does apply to the target's set of restricted capabilities, an error communication protocol can provide an error message to a user attempting to use the feature for display. For example, an access control runtime component (e.g., RBAC runtime) can use a feature to command mapping database to locate relevant features to be validated using one or more validation rules and/or one or more sets of capabilities and/or restricted capabilities as part of providing license enforcement and monetization features.
As shown in
For example, an RBAC runtime system can use aspects of the model to control action and/or command inputs by packaging and sending error messages to administrators and/or end-users due in part to identified capabilities that can include a number of restricted capabilities associated with a target user or object. The model allows for monetization in the case of licensing certain features that should be restricted regardless of the user, device, and/or application attempting to make a change. For example, customers wanting to differentiate a pricing structure may want to give remote users more capabilities than other users sitting at desks who do not need additional protocols. Such a model provides a mechanism to control price by giving users that need the features greater features, while other users get lesser features for a lower price of as part of subscribing to a service or use of a resource.
As shown, the role-based computing infrastructure 104 includes an RBAC runtime component 108, roles component 110, scopes component 112, validation component 114, feature mappings component 116, and capabilities identifier component 118. As described below, validation rules and identified sets of capabilities can be used in addition to, or simultaneously with, a scope check to ensure that administrator and end-user commands comport to or comply with a license or monetization feature. For example, a scope check can include the use of absolute and relative scopes, wherein absolute scopes are independent of a user and relative scopes relate to at least one of self, groups, distribution groups, reports, etc.
A scope can include a set of objects on which tasks defined in a role can operate. Accordingly, a scope can be used to define allowable actions and/or unallowable actions. In an embodiment, a scope of a derived role cannot exceed the scope of a parent role from which the derived role is generated. A derived role can be scoped to any appropriate actions and action parameters of the parent (e.g., existing) scope from which the derived role is generated. Entry modification (e.g., removal) can be performed to further narrow the scope of the derived role. As described below, in addition to user based rules, such a scope and validation rule model can be applied to any object as long as the object can be marked up with one or more capabilities.
In one embodiment, capabilities can be stored in a dedicated directory server on the user object, such that each user has an identifiable set of capabilities associated with a particular subscription or license type. For example, the RBAC runtime component 108 can use a directory service to determine sets of capabilities for end-users as part of processing command inputs and communicating error messages to an issuing user (administrator, tenant administrator, end-user, etc.) which may result in selection of and payment for an additional service or feature (e.g., prelicense, upgrade, update, etc.).
As shown in
The role-based validation infrastructure can use a common set of primitives that represent actions of end-users, partners, tenants, datacenter administrators, enterprise administrators, and/or other users. The primitives can be represented by commandlets (cmdlets) and API calls, but are not so limited. A role of one embodiment includes role actions and a number of action parameters that define permissions associated with a role. Roles can be assigned in several ways, such as direct assignment, assignment to a security group or other object, and/or assignment to a policy (and then assigned to numerous end-users) as examples. Assignments can be created, retrieved and managed using a common tool set.
In one embodiment, the architecture 100 uses a role and capabilities based layer as part of providing an administration of network services and/or resources. The layer can use the roles component 110 to define roles that represent administrative actions and associated action parameters, and the scopes component 112 to define scopes to be associated with the roles, wherein the scopes define objects on which the administrative actions and action parameters operate. In one embodiment, the scopes component 112 can also define and manage custom scopes, organizational unit (OU) scopes, relative scopes, absolute scopes, filter-based scopes, and/or other types of scopes. For example, validation rules can be based in part on aspects of a scope type.
Roles, scopes, and associated validation rules can be implemented to provide management actions for multi-tenant hosted service administration. The roles, scopes, and validation rules can also control management actions for tenant administration and also for self-service administration operations. In one embodiment, the architecture 100 includes a centrally located storage component for storing roles, scopes, and/or sets of capabilities for administration of user actions. In another embodiment, validation rules and/or command/action to feature mappings can also be stored in central storage or each can include a dedicated server. Other embodiments are available. Exemplary roles can include an enterprise administrator role, enterprise end-user role, tenant administrator role, tenant end-user role, a datacenter administrator role, a partner role, managed role, federated role, cloud access role, etc.
Acting as an additional layer of security, a validation layer including the validation component 114 uses one or more validation rules to ensure that administrator actions associated with an intended target or targets comply with the one or more validation rules even when the scope check is satisfied. As described below, the capabilities identifier component 118 can use a role in part to determine an associated set of capabilities and/or restricted capabilities. The capabilities identifier component 118 of an embodiment can also define and/or redefine capabilities for various users, objects, and/or groups. In one embodiment, an object can be populated with capability information include metadata defining an associated set of capabilities for use by the validation component 114 when applying validation rules as part of allowing or disallowing a command or action associated with some feature or feature set. As described below, feature mappings 118 can include command and/or action to feature mappings for use in implementing a license enforcement process, privacy violation determination, or other role-based control mechanism.
In an embodiment, a set of capabilities can be attached to an object as metadata, wherein the set of capabilities are based on defined features of some application or resource, such as provided by enterprise business service application vendors for example. In one embodiment, capabilities and/or restricted capabilities can be based in part on one or more stock keeping units SKUs to control and/or limit use of certain command, actions, and/or other features. SKUs can be used in part to manage segments of target software features or markets, including enforcement of allowed and/or disallowed features and/or actions. For example, a SKU parameter can be used in part to send an error message to an administrator upon attempting to perform some action within a role-based business productivity application, wherein the action is disallowed for the particular SKU. Each SKU of one embodiment includes a set of capabilities that dictate a unique set of features/limits that a customer can purchase or use. For example, online application services and features can be offered for consumer purchase, wherein all or particular portions of offered services and/or features can be purchased and used in accordance with purchase and/or license agreement or terms.
In one embodiment, a set of capabilities can be used with a number of validation rules in part to define and control access to different levels or portions of service or resource as part of an online service offering. As one example illustrating use of SKUs, mailboxes and other communication features can be provisioned to include only the set of features allowed by an assigned SKU (e.g., cloud, enterprise, local-only, etc.) as dictated by an associated plan assignment. As another example of use of SKUs, mailboxes and file storage features can be provisioned to include only the set of features allowed by an assigned SKU as dictated by an associated privacy assignment.
As another example, SKUs can be used in part to control and or manage inadvertent or intentional administrator change or changes that may violate a users or group of user's license or assigned set of capabilities. A validation process of one embodiment can be used as part of controlling or limiting the number of features to be enforced, including focusing on high value features to provide amounts of revenue, while allowing reasonable controllable aspects and also ensuring that managed controls do not create significant take backs (e.g., user dissatisfaction/unsatisfactory experience) from the administer and on-premise experience. In alternative embodiments, one or more of the components can be further divided or combined. For example, a dedicated server can be implemented to disconnect resources and/or application services such that no direct communication link is provided to any client. In one embodiment, a server and associated resources can be dedicated to implement RBAC components including an RBAC application, runtime services, and/or administration services.
The functionality described herein can be used by or part of a computing system, including provided as part of a hosted system, application, or other resource. In one embodiment, the architecture 100 can be communicatively coupled to a file system, virtual web, network(s), and/or other information sources as part of providing role-based validation features. An exemplary computing system includes suitable programming means for operating in accordance with a method of enforcing license provisions or terms.
Suitable programming means include any means for directing a computer system or device to execute steps of a method, including for example, systems comprised of processing units and arithmetic-logic circuits coupled to computer memory, which systems have the capability of storing in computer memory, which computer memory includes electronic circuits configured to store data and program instructions. An exemplary computer program product is useable with any suitable data processing system. While a certain number and types of components are described above, it will be appreciated that other numbers and/or types and/or configurations can be included according to various embodiments. Accordingly, component functionality can be further divided and/or combined with other component functionalities according to desired implementations.
The process 200 of an embodiment can be used as part of a hosted space/computing environment as part of focusing on areas of monetization of an offered service, including the requisite enforcement of licenses and associated terms and/or conditions. For example, an application and computing platform can be used to provide features of an online business productivity suite/computing architecture that is offered to customers through some number of varying subscription types as part of providing role-based access control and/or other control features.
In one embodiment, the process 200 uses RBAC features including use of a number of validation rules in conjunction with one or more identifying features as part of controlling and monetizing aspects of an offered service. An RBAC system provides role-based scoping and validation mechanisms as part of providing a robust security and compliance strategy to protect critical business resources including digital assets, computing and network resources, databases, online service offerings, data center frameworks, etc. For example, a RBAC system runtime uses the process 200 and one or more SKUs to control access to various subscribed to and licensed features. Each SKU of one embodiment includes a set of capabilities that dictate a unique set of features/limits that a customer can purchase or use. For example, online application services and features can be offered for consumer purchase, wherein all or particular portions of offered services and/or features can be purchased and used in accordance with a purchase and/or license agreement or terms.
In one embodiment, a set of capabilities can be used in part to define and control access to different levels or portions of an online service that a customer can purchase and use as part of an online service offering. In one embodiment, at provisioning time, mailboxes and/or access permissions can be configured with only the set of features allowed by an assigned SKU, dictated in part by a mailbox plan assignment for example. The process 200 can operate to control and or manage inadvertent or intentional administrator changes that may violate a users or group of user's license or assigned set of capabilities. The process 200 of one embodiment can be used as part of controlling or limiting the number of features to be enforced, including focusing on high value features that can be reasonably controlled while ensuring that the managed controls do not create significant limitations or drawbacks from the administer and on-premise experience.
For example, the process 200 can include various RBAC features, as shown by the examples in Table 1 below.
With continuing reference to
As shown by the examples above, validation rules can be used, but are not so limited, to: ensure that administrators do not violate a license by modifying a mailbox or other specified property; ensure that administrators do not violate a license using Global Cmdlet Based Features; ensure that administrators do not violate a license through a Role Assignment; and/or ensure that administrators do not violate a license by modifying or assigning an inappropriate Policy. For example, an RBAC service can be used to expose functions as part of creating and managing roles, resources, permissions, validation rules, user role assignments, resource permission assignments, and/or associated RBAC policies.
At 204, the process 200 operates to determine whether administrator and/or role-based user command inputs map to a defined feature(s) or action(s) based in part on one or more feature to command mappings. In one embodiment, the process 200 at 204 uses an RBAC runtime system and a mapping database to process administrator command inputs as part of determining whether the command input violates a license term or aspect while enabling administrators to fully manage a “Managed” user base and being prevented from changing any on-premise mastered properties of a “Federated” user base. Exemplary properties include, but are not limited to:
NewUserPasswordManagementPermissions;
NonFederatedModeratedRecipientsPermissions;
NonFederatedRecipientManagementPermissions;
ProfileUpdatePermissions; and/or
ResetUserPasswordManagementPermissions.
At 206, the process 200 operates to identify whether one or more validation rules are associated with the determined feature or action. For example, the process 200 at 206 uses the RBAC runtime system and a validation rules component as part of identifying the one or more validation rules to be applied for the particular feature or action. At 208, the process 200 operates to examine a set of capabilities associated with each target (e.g., user object, capability object, etc.) user as part of determining whether to allow the command input. For example, the process 200 at 208 can use the RBAC system and a directory component (e.g., ACTIVE DIRECTORY system) to identify one or more sets of capabilities of users targeted by the command according to a role type.
In one embodiment, each set of capabilities can be determined or assigned based in part on a type of license, agreement, assignment and/or term(s) of a use contract as examples. For example, mailboxes and/or other resources can be configured at provisioning time with only the set of features/capabilities allowed by an associated SKU as dictated by an associated Mailbox Plan assignment. At 210, the process 200 operates to send a communication (e.g., error message) to the command initiator and/or target(s) if there is a validation rule violation for the associated set of capabilities. In one embodiment, the process 200 at 210 also operates to communicate a message and/or process the command if an associated set of capabilities conforms or complies with one or more validation rules. For example, the RBAC runtime system can issue a message associated with a validation rule violation or process the command or request based on whether an associated validation rule evaluates to true or false (e.g., LICENSE VIOLATION: You may not perform the <Action> on <User> with assigned license <Capability ID>).
The process 200 of an embodiment controls management of a population that spans multiple plans/capability sets, which includes using granted management rights over a superset of features that may be granted to any of the associated users. The process 200 can be used in part to work with a paid service based on the features offered within a given level as part of preventing administrators from violating terms of a license agreement, regardless of intent. The process 200 of one embodiment defines and/or uses permissions according to constraints, conditions, and/or terms of a license using business logic defined in part by assignees of the business logic, using roles, scopes, a set of capabilities, a set of restricted capabilities, and/or a number of associated validation rules. For example, the process 200 can be used to prevent tenant administrators from performing specific actions on specific users or objects.
The process 200 can be used to enable license enforcement and monetization of segmented features that include absolute administrator oversight and management, whereas other features can simply be tenant admin immutable, wherein the validation rules that are used to prevent a license violation are administrator immutable. As one example, the process 200 can operate to send a message for an unauthorized action or command as a result of application of an associated validation rule that includes an informative reason that makes the violation clear to the Administrator or user. In other embodiments, the process 200 that operates to prevent license violations is consumable by various user interfaces and/or applications to segment out features based on one or more validation rules. Other embodiments are available.
For example, an RBAC runtime system can use aspects of the model to control action and/or command inputs by packaging and sending error messages to administrators and/or end-users due in part to identified capabilities that can include a number of restricted capabilities associated with a target user or object. The model allows monetization in the case of licensing as certain features should be restricted regardless of the user attempting to make a change. In addition to user based rules, such a model can be applied to any object as long as the object can be marked up with a set of capabilities.
Such a model and associated components allow for separation of business logic, such as license enforcement from concepts, such as Roles, Scopes and Role Assignments for example, by using a capability-driven validation mechanism when processing command inputs. In one embodiment, a RBAC runtime component (see
In one embodiment, such a validation rule check includes, but is not limited to: identifying if an action or command is associated with a defined feature (e.g. Set-CASMailbox −ImapEnabled $True is associated with the IMAPPermissions feature); identifying any validation rule or rules associated with such a defined feature, including retrieving or identifying a set of restricted capabilities (e.g. The feature ImapEnabled is restricted from users with a set of capabilities that includes Deskless user); examining target user(s)/object(s) set of capabilities and/or restricted capabilities to determine whether the rule applies; and allowing execution of the action if the rule does not apply to the target's set of restricted capabilities, or providing/displaying an error message if the rule applies to the target's set of restricted capabilities. For example, the RBAC runtime can use a feature to command database to locate relevant features to be validated using the validation rules and one or more sets of capabilities and/or restricted capabilities as part of providing license enforcement and monetization features.
The model of one embodiment uses a new syntax and provides a central location for feature teams to define validation rules for associated features and a given defined population of users, independent of feature code. In one embodiment, a role-based computing infrastructure includes an ability to store or calculate a per-user/object set of capabilities (e.g., a definition of a user population) against which a rule can be evaluated, wherein a given rule can be associated with a context specific error message. Correspondingly, implemented validation rules account for a target user state or set of capabilities, which can be stored directly or calculated based on per-user or global settings. While the model is applicable to license enforcement and monetization aspects, it can also be used in other control type scenarios.
As shown in
In one embodiment, an RBAC-based computing architecture (e.g., an EXCHANGE server infrastructure) is configured to enable component teams to easily define particular validation rules dependent in part on one or more capabilities or features, wherein business logic based rules can be implemented using an RBAC-based validation mechanism. Using such a model allows enforcement of both administrative actions as well as self-service actions where a user is making a change to an associated user object.
With continuing reference to
The capability identifier evaluator 302 of one embodiment uses a capability identifier attribute of an object to denote object assigned capabilities or features. A capability identifier of an object can contain multiple capabilities (i.e., based on SKU, license, product offering, etc.) that can be used part of assessing a set of capabilities for a particular user. In an embodiment, the capabilities can be used as part of performing license enforcement operations, wherein the capabilities can be persisted in a directory structure, such as an ACTIVE DIRECTORY data structure for example.
A capability identifier 304 can be defined as enumeration (enum), as shown by the example:
Exemplary capabilities can be based on and include, but are not limited to, a mailbox SKU (e.g., desk-less, standard, enterprise, etc.), managed, unmanaged, federated, signed time of use (TOU), etc. For example, such capabilities can be read directly using a directory object including capability attributes and/or multi-valued property or properties and values associated with the attributes. Exemplary capabilities can also be based on and include calculated types including filter like definitions, such as large quota, Messaging Application Programming Interface (MAPI) enabled, Internet Message Access Protocol (IMAP), etc.
The Validation Rule Definition 306 holds a definition of a validation rule, containing the information associated with a business rule to enforce on an object, such as ADObjects for example. One example:
The validation rule 308 consumes the Validation Rule Definition 306. In one embodiment, the validation rule 308 can be evaluated during a scope check, such as an ADScope check for example. As an example:
The Scope Set 310 of an embodiment is an extended object will be extended to include a list of applicable validation rules (e.g., contains a list of Validation Rules). As an example:
For example, an AD Driver API can be overloaded to allow specifying a list of validation rules to apply on a given object (e.g., call Validate on all the Validation Rules). RBAC validation rules list 312 contains a list of all validation rules definitions available and provides an API to add/remove/search for rule definitions. In one embodiment, a singleton pattern is used having one instance per process. As an example:
The Runspace Configuration 314 is configured to populate the Scope Set 310 with a set of applicable rules. For example, the Runspace Configuration 314 can operate to populate the Scope Set 310 with a set of applicable rules for a given cmdlet/parameter only if the executing user is a Tenant User type, querying a single global instance of RBAC Validation Container for the information.
The Validation Rules parser 316 operates to validate that for every rule definition the given feature definition exists and perform an example correlation: Rule Definition to Feature Definition to Cmdlet/Parameter including using cmdlet configuration entries. The parsing, validation, and population of validation rules can be performed as:
1. Parse during compile time, validate the XML, correlate Rules Definition to Feature to Cmdlet, and generate the appropriate code (e.g., C#) to populate the RBAC Validation Rules List 312; or,
2. Parse at runtime and during compile time only validate the XML for sanity check. At runtime, parse and perform the exemplary correlation Rules Definition to Feature to Cmdlet. In one embodiment, regardless of the parsing method, the rules can be populated by using ‘Cmdlet Configuration Entries’ to call an object responsible for populating the RBAC Validation Rules List 312.
Validation Rules Definitions of one embodiment are tied to service plan features, enabling component teams to define service plan features and specify a validation rule applicable to each feature. As an example,
public static readonly FeatureDefinition ResetUserPasswordManagementPermissions=
new FeatureDefinition(“ResetUserPasswordManagementPermissions”,
Exemplary definitions are shown in Table 2 below:
Moreover, for this example:
An exemplary Rule Definition can be defined as follows:
And, an exemplary Validation Rule Definition can be defined as follows:
And,
And, for this example, a Runtime Applicable ADScope filter example:
When a ‘cmdlet’ scope verification is done on a given object and no ‘parameter’ is specified, validation rules may not be enforced. In one embodiment, a change is made to the cmdlet scope check on a target object to account for such a scenario as shown by the following example processing flow. If parameters are specified, then apply the validation rules applicable to the specified parameters. If no parameters are specified, then get the list of all parameters that the current executing user has access to and for every parameter get all the applicable validation rules, then if all rules are satisfied for the given object, the parameter stays. Otherwise, if at least one rule fails for the given object, then remove the parameter. Then, check the list of parameters. If the list of parameters is empty, then cmdlet Scope verification for the given object failed and the current executing user is not able to execute the given cmdlet on the object, since regardless of the parameters used, all of them violate a license on the target user. If the list is not empty, then cmdlet Scope verification for the given object succeeds and the user is able to execute the cmdlet with at least one parameter on the given object without breaking any rule.
As part of a preemptive validation rules evaluation, a validation rules evaluation algorithm used for cmdlet Scope verification on object can also be applied during initialization to remove all end-user role entries that may lead to a licensing violation for the current executing user, assuming users that do not have any role assignment that grants the same cmdlet through an end-user role and admin role. The model of one embodiment enables an ability to easily define validation rules as metadata as part of introducing and managing validation rules lifecycles, including using validation rules required to meet licensing, legal, and/or technical product requirements. Validation rules can also be defined and stored. In one embodiment, exemplary validation features allow mail administrators to define policies which take into account real-time availability and performance of servers. Due in part to different licensing or legal requirements, validation rules can be implemented such that a given rule or rules may only be applied where applicable.
Validation rule lifecycle management operations can include, but are not limited to: adding a new rule to a validation group, wherein a rule can be applied to all actions across all servers upon deployment; disabling a rule within a validation group including persisting rules in metadata but not to be applied at runtime; and/or removing a rule from a validation group, including removing a rule from the metadata and not applying the removed rule to any runtime actions. Validation rules can apply to both to end-user and administrator actions. For example, a validation rule such as the Managed/Federated requirement that users who are Federated may neither have their password reset nor be able to reset their own password, should apply regardless of whether an Admin or the end-user themselves try to run the “Set-User—Password” task.
Validation rules can also be defined on a per task/parameter basis to restrict only a given parameter of a task. For example “Set-Mailbox—PopEnabled” from being run against a population of Deskless users. Capabilities can be grouped along with localizable error messages specific to each group as part of grouping similar, dependent, and/or related capabilities into groups. For example, a licensing group can be created that identifies all of the licensing specific capabilities as well as a set of licensing specific error messages.
In one embodiment, a discoverability process includes an ability to report on user and capability restrictions so administrators are provided with a tool to identify which features are restricted from a user or group based on RBAC based validation rules that enable, but are not so limited: an administrator to readily identify features that are restricted from a given user or object and also identify which features are restricted from users with a given capability or set of capabilities.
Table 3 lists exemplary Capabilities and Error Strings to meet BPOS standard license enforcement requirements.
Table 4 lists exemplary validation rules for such capabilities for these examples include, but are not limited to:
Table 5 lists exemplary Capabilities and Error Strings required to meet BPOS standad license enforcement requirements.
Table 6 lists a number of exemplary validation rules that can be used as part of a migration operation.
Table 7 lists exemplary Federated User Enforcement Capabilities and Error Strings to meet BPOS standard license enforcement requirements.
Table 8 lists a number of exemplary validation rules to manage a federated user operation.
Some examples illustrate use of the validation mechanism in the enterprise context as part of ensuring that administrators do not violate a license by modifying some licensable user feature, such as a mailbox property for example, while at the same time providing moderated control over some user features (e.g., IMAP, MAPI, POP, ActiveSync, etc.) and preventing entering some operational state that violates some term or terms of an assigned license. For example, the validation features can be used in part to wherein the roles and scopes provide management actions for tenant service administration, multi-tenant hosted service administration, enterprise administration, partner service administration, and datacenter service administration.
Consider a scenario where an organization has purchased subscriptions to a Deskless SKU, a Standard SKU, and an Enterprise SKU defined by the examples in Table 9. In one embodiment, the validation rules track subscription types as part of enforcing license terms.
Since an administrator may at any time have users that are assigned the Enterprise SKU it follows that they would need the ability to manage Enterprise Features such as enabling/disabling IMAP for individual users. However by simply giving an Administrator such a right may allow for enabling IMAP for users assigned the DeskLess SKU which could be in violation of an assigned license. Thus, a subscription may come with a bundle of administrator rights, which may violate terms of the assigned license when implemented on certain target users (e.g., DeskLess) or objects.
Illustrates ensuring that administrators do not violate a license by modifying or assigning an inappropriate Policy. For example, the validation mechanism described above can be used as part assessing one or more levels of indirection for Advanced Mobile Device Policies and Retention Policies as part of monetizing features that administrators are allowed to modify and/or assign.
Assume a simple example SKU model as shown in Table 10.
Retention Policies are effectively a double indirection because it is the type of the Retention Tags that are associated with a Retention Policy that dictate whether a policy applies to a Default Folder or to any folder, such that logic can be used to identify tags associated with a given Retention Policy at association time. Logic can be included to prevent adding a retention tag to a Retention Policy if adding a particular tag would violate the license of any of the currently assigned users using logic to identify all existing retention policy assignments. Policy management can be used in part to ensure that administrators do not set inappropriate (license violating) features on a given policy object including examining a capability set that the policy applies to. Policy assignment can be used to ensure that a user is not assigned a policy that would result in license violation using logic to identify the capabilities of the user as well as the policy object. A policy can be created along with a Mailbox Plan to ensure that the policy is properly tied and/or defaulted to a capability set.
Ensuring administrators do not violate a license through using a “Global” feature as part of monetizing a number of global organizational features, illustrated by the examples in Table 11.
For Non-Cmdlet Based ITPro Features the issue is highlighted by the asterisk ‘*’, the feature is enabled or used fully independent of any given user object and is not confined within Cmdlet Execution. Since this is a service runtime rather than a cmdlet based action that needs to be restricted, RBAC may not necessarily be required to come into play in the authorization path.
For example the difference between a Journal Rule applied per Database and a Journal Rule applied per user is the use of the New-JournalRule cmdlet. However, once this cmdlet is granted to an Administrator there is nothing to say that she can't create New-JournalRules that apply to a DeskLess or Standard user. Worse is that she could apply the New-JournalRule to a Distribution Group which could contain Deskless, Standard or Enterprise users at any point in time as Distribution Group membership should be assumed fluid over time. For Cross Mailbox Search and Legal Hold can be fully Cmdlet Execution controlled since the RBAC infrastructure is part of the authorization path for the actions. Cross Mailbox Search can imply that an action that can be performed across multiple mailboxes will be restricted on a per-mailbox basis depending on their assigned capability set.
Ensuring administrators do not violate a license through a Role Assignment using the association between RBAC Roles and Mailbox Plans, as illustrated by the examples in Table 12.
In order to ensure that an Administrator who is managing RBAC Role Assignments to the Role Assignment Policy associated with the Deskless worker SKU (set of capabilities) does not inadvertently grant these users the right to use either of these ECP features, ensure that a grant limited to end-user roles that are associated with the Deskless capability set to the Role Assignment Policy that is somehow similarly associated with the Deskless capability set. Other examples and embodiments are available.
In one embodiment, a command-line shell (e.g., WINDOWS POWERSHELL) can include an interactive prompt and a scripting environment, used independently or in combination. For example, the shell can be built on top of a framework common language runtime (CLR) and associated framework (e.g., .NET), including accepting and returning framework objects. In one embodiment, a command-line shell includes a single-function command-line tool, termed a cmdlet as part of the shell. A cmdlet is a lightweight command that is used in the POWERSHELL environment. The POWERSHELL runtime invokes cmdlets within the context of automation scripts that are provided at the command line. The POWERSHELL runtime also invokes them programmatically through APIs.
Cmdlets perform an action and typically return a.NET Framework object to the next command in the pipeline. A cmdlet attribute includes a .NET Framework attribute that is used to declare a cmdlet class as a cmdlet. Cmdlet parameters includes required, named, positional, and switch parameters. Switch parameters allow defining of parameters that are evaluated only if the parameters are specified in a call. A parameter set includes a group of parameters that can be used in the same command to perform a specific action. A cmdlet can have multiple parameter sets, but each parameter set must have at least one parameter that is unique. A dynamic parameter is a parameter that is added to the cmdlet at runtime.
At 408, the process 400 of one embodiment operates to send an error message to a command initiator if the target has restricted capabilities according to the applicable validation rule, otherwise the process 400 proceeds to 404. At 410, the process 400 of an embodiment operates to send an upgrade message to a command initiator upon a successful license upgrade, including confirmation of payment or promise of payment and alert that the previously applicable validation rule is no longer applicable; otherwise the process 400 proceeds to 402. While a certain number and order of operations is described for the exemplary flow of
While certain embodiments are described herein, other embodiments are available, and the described embodiments should not be used to limit the claims. Exemplary communication environments for the various embodiments can include the use of secure networks, unsecure networks, hybrid networks, and/or some other network or combination of networks. By way of example, and not limitation, the environment can include wired media such as a wired network or direct-wired connection, and/or wireless media such as acoustic, radio frequency (RF), infrared, and/or other wired and/or wireless media and components. In addition to computing systems, devices, etc., various embodiments can be implemented as a computer process (e.g., a method), an article of manufacture, such as a computer program product or computer readable media, computer readable storage medium, and/or as part of various communication architectures.
The term computer readable media as used herein may include computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory, removable storage, and non-removable storage are all computer storage media examples (i.e., memory storage.). Computer storage media may include, but is not limited to, RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store information and which can be accessed by a computing device. Any such computer storage media may be part of device. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.
The embodiments and examples described herein are not intended to be limiting and other embodiments are available. Moreover, the components described above can be implemented as part of networked, distributed, and/or other computer-implemented environment. The components can communicate via a wired, wireless, and/or a combination of communication networks. Network components and/or couplings between components of can include any of a type, number, and/or combination of networks and the corresponding network components include, but are not limited to, wide area networks (WANs), local area networks (LANs), metropolitan area networks (MANs), proprietary networks, backend networks, etc.
Client computing devices/systems and servers can be any type and/or combination of processor-based devices or systems. Additionally, server functionality can include many components and include other servers. Components of the computing environments described in the singular tense may include multiple instances of such components. While certain embodiments include software implementations, they are not so limited and encompass hardware, or mixed hardware/software solutions. Other embodiments and configurations are available.
Referring now to
Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
Referring now to
The mass storage device 14 is connected to the CPU 8 through a mass storage controller (not shown) connected to the bus 10. The mass storage device 14 and its associated computer-readable media provide non-volatile storage for the computer 2. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed or utilized by the computer 2.
By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks (“DVD”), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer 2.
According to various embodiments of the invention, the computer 2 may operate in a networked environment using logical connections to remote computers through a network 4, such as a local network, the Internet, etc. for example. The computer 2 may connect to the network 4 through a network interface unit 16 connected to the bus 10. It should be appreciated that the network interface unit 16 may also be utilized to connect to other types of networks and remote computing systems. The computer 2 may also include an input/output controller 22 for receiving and processing input from a number of other devices, including a keyboard, mouse, etc. (not shown). Similarly, an input/output controller 22 may provide output to a display screen, a printer, or other type of output device.
As mentioned briefly above, a number of program modules and data files may be stored in the mass storage device 14 and RAM 18 of the computer 2, including an operating system 24 suitable for controlling the operation of a networked personal computer, such as the WINDOWS operating systems from MICROSOFT CORPORATION of Redmond, Wash. The mass storage device 14 and RAM 18 may also store one or more program modules. In particular, the mass storage device 14 and the RAM 18 may store application programs, such as word processing, spreadsheet, drawing, e-mail, and other applications and/or program modules, etc.
It should be appreciated that various embodiments of the present invention can be implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention.
Accordingly, logical operations including related algorithms can be referred to variously as operations, structural devices, acts or modules. It will be recognized by one skilled in the art that these operations, structural devices, acts and modules may be implemented in software, firmware, special purpose digital logic, and any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims set forth herein.
Although the invention has been described in connection with various exemplary embodiments, those of ordinary skill in the art will understand that many modifications can be made thereto within the scope of the claims that follow. Accordingly, it is not intended that the scope of the invention in any way be limited by the above description, but instead be determined entirely by reference to the claims that follow.
This application is a divisional of U.S. application Ser. No. 12/962,897, filed Dec. 8, 2010, entitled Monetizing Product Features as Part of Enforcing License Terms, the disclosure of which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12962897 | Dec 2010 | US |
| Child | 14883707 | US |
