text:
Systems and methods for delegating access to resources hosted in a distributed computing environment are described. In one aspect, a server hosts a set of resources. The server receives a request from a user to perform an operation with respect to one of the hosted resources. Responsive to receiving the request, the server determines whether the user has already been delegated authority to perform the operation. The delegated authority is independent of whether the user is a member of an administrators group associated with any resource of the server.
This patent application is related to U.S. patent application Ser. No. 10/281,083, titled “Role-Based Authorization Management Framework”, filed on Oct. 26, 2002, commonly assigned to the assignee hereof and hereby incorporated by reference.
The invention pertains to administration of network service provider hosted resources.
Administrating Web sites can be time consuming and costly, especially for entities that manage large Internet Service Provider (ISP) installations. To save time and money, many ISPs support only large company Web sites, at the expense of personal Web sites. One reason for this is because computer security has become increasingly important not only to businesses and other organizations, but also to individuals. To meet such security needs, computer and Web site security strategies must be selected and enforced for each administrative scenario. Such selection and enforcement make it considerably labor and time intensive and expensive to support personal Web sites.
FIG. 1 shows an exemplary computing environment within which systems and methods for delegating administration of a hosted resource may be implemented.
FIG. 2 shows further exemplary aspects of system memory of FIG. 1, including application programs and program data for delegating administration of a hosted resource.
FIG. 3 shows an exemplary procedure for delegating administration of a hosted resource.
Reliable, scalable, manageable, and secure systems and methods to delegate and implement remote administration of Web sites are described. In particular, an Internet Service Provider (ISP) computer server administrator utilizes the following described Internet Information Services (IIS) Delegation Administration (DA) framework to delegate specified Web site administration tasks to authorized users for execution. Such an authorized user may include, for example, a user that owns a personal Web site hosted by an ISP.
User authorization is determined in view of specified role-based access permission(s) to perform specified application operations associated with the hosted Web site. This IIS DA framework obviates existing trends involving computer security, wherein personal Web sites are not supported due to the inefficiencies of time and cost, as described above. One reason for this is because an administrator is not required to intervene (i.e., to ensure computer security and authorized access) every time a hosted personal Web site is modified or tested. Such modifications may include, for example, change of Web site content/functionality such as deployment of a new application on the Web site, etc.
These and other aspects of the systems and methods for delegated Web site administration are now described in further detail.
FIG. 1 illustrates an example of a suitable computing environment 120 on which the subsequently described systems, apparatuses and methods for delegating administration of a hosted resource may be implemented. Exemplary computing environment 120 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of systems and methods the described herein. Neither should computing environment 120 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in computing environment 120.
The drives and associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules, and other data for computer 130. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 148 and a removable optical disk 152, it are appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and the like, may also be used in the exemplary operating environment.
A user such as an ISP Web site administrator may provide commands and information into computer 130 through input devices such as keyboard 166 and pointing device 168 (such as a “mouse”). Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, digital camera, etc. These and other input devices are connected to the processing unit 132 through a user input interface 170 that is coupled to bus 136, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB).
A monitor 172 or other type of display device is also connected to bus 136 via an interface, such as a video adapter 174. The monitor can be utilized, for example, to present a user interface (UI) associated with the described systems and methods to delegate Web site administration, for example, by defining application access policies and rules as described below. In addition to monitor 172, personal computers typically include other peripheral output devices (not shown), such as speakers and printers, which may be connected through output peripheral interface 175.
Depicted in FIG. 1, is a specific implementation of a WAN via the Internet. Here, computer 130 employs modem 178 to establish communications with at least one remote computer 182 via the Internet 180. In a networked environment, program modules depicted relative to computer 130, or portions thereof, may be stored in a remote memory storage device. Thus, e.g., as depicted in FIG. 1, remote application programs 189 may reside on a memory device of remote computer 182. The network connections shown and described are exemplary. Thus, other means of establishing a communications link between the computing devices may be used.
FIG. 2 is a block diagram that shows further exemplary aspects of system memory 134 of FIG. 1, including application programs 160 and program data 164 for delegating administration of a hosted resource. In this implementation, application programs 160 include, for example Authorization Module 202, Delegation Module 204, Remote Client Web Site Administration (RCWA) module 206 (i.e., the “requesting application”), Execution Module 208, and Authorized Process(es) 210. For purposes of discussion, these application programs in conjunction with selected other features of the system 100 of FIG. 1, are hereinafter often referred to as the “Internet Information Services (IIS) Delegated Administration (DA) Framework, or “framework”.
The Authorization Manager 202 provides security support for delegating administration of a hosted resource of IIS metabase nodes (i.e., nodes of the IIS metabase 212). The IIS metabase 212 identifies nodes for applications, resources, or objects hosted, deployed, and/or managed by the computer 130 of FIG. 1. More particularly, the metabase is a hierarchical store of configuration information and schema that are used to configure IIS. In existing systems, only users who are members of the Administrators group can view and modify a resource represented by a metabase node. In contrast to such conventional systems, the IIS DA framework, which is now being described, allows users other than those in the Administrators group (e.g., application administrators) such as Web site owners to view and/or modify particularly specified portion(s) of the IIS metabase 212. For purposes of this description, a “user” is an individual that is not assigned to the Administrative group, although a user could also be of the Administrators group.
To this end, the Authorization Manager Module 202, via selective interaction with the Delegation Administration (DA) module 204, allows an administrative entity (i.e., a member of the Administrators group) to specify (e.g., specify via a UI displayed on the display device 172 of FIG. 1) user access permissions to nodes of the IIS metabase 212. The Authorization Manager Module 202 writes such user access permissions (i.e., policies/rules) to Authorization Policy Store 214. In one implementation, such access permissions are represented, for example, in Extended Markup Language (XML), Active Directory, Software Query Language (SQL), or some other data format.
An application queries the APS 214 (via API's 216 exposed by the Application Manager 202) at run time to confirm that a client is authorized to perform a requested operation on a resource. Authorization Manager provides APIs for managing authorization policy and validating access control and a user interface for administrators so that they can manage the authorization policy store.
An application as specified by the Authorization Policy Store (APS) 214 is a top-level node of the Authorization policy store 214. An application specifies the operations or tasks that the application can perform and declares them in the APS 214, for instance, when the application is installed. An application specification includes administrator identified application specific roles in terms of the task and operations that are needed to perform a job (e.g., in an organization). The definitions of roles, tasks and operations (methods), and scopes are stored in the APS 214. A role is an authorization or resource configuration role (e.g., an organizational permission on some set of resources). An authorization role is based on a user's job function. A resource configuration role is based on a computer's function.
A task is a collection of low-level operations. The purpose of the task is to determine which low-level operations do some unit of work that is meaningful to administrators. An example of a task might be Change Password. Tasks can also contain other tasks. For example, a task called Manage User Accounts may include the tasks Change Password, Reset Password, Disable Account, and so on.
An operation is a low-level permission that a resource manager uses to identify security procedures. Several operations may be used to perform a meaningful task. (Operations are often not exposed or meaningful to administrators). An example of an operation could be WriteAttributes or ReadAttributes. A scope is collection of one or more physical or logical resources (e.g., a folder and/or files) associated with a respective authorization policy. An application can use the scope to group resources, to map a user requested resource to a scope (e.g., when an application checks for user access), and so on.
In this implementation, the Authorization Manager 202 allows specification of zero (0) or more groups and corresponding roles for each specified group member. A group corresponds to a user's role, and an application administrator specifies the permissions that are needed by the role by granting the group permission in an ACL for an object (e.g., application, resource, etc.). TABLE 1 shows an exemplary application definition of the APS 214, which in this implementation, is in an XML data format.
Each application includes numerous attributes such as a substantially globally unique identifier (a “GUID”, e.g., d9089f17-5fa6-4ae9-bddf-8ca6cd1c06fb), a name (e.g., SiteAdminApp), and so on. Application attributes are used, for instance, to identify particular ones of the applications specified in the authorization policy store 214. In the example, of TABLE 1, the application includes a group (e.g., see tag pair “AzApplicationGroup”) to specify one or more users assigned to one or more “roles” with respect to the application. A role is a set of permissions assigned to a user to enable the user to perform a set of tasks. Each application group includes a GUID attribute (e.g., value bf9d00f0-2be3-4367-a931-680038b51d0a) and a name attribute (e.g., GroupMetabaseChangeDefaultDoc). This exemplary group illustrates a single member identified by SID: S-1-5-21-3131233723-616130271-937215924-1032. For the purpose of this example, assume that this is the SID is associated with a user, “User1”.
In this implementation, a role is applied to a set of associated objects, and then a group of users is assigned to the role.
The application of TABLE 1 includes an application group (although any number of such groups could be defined) with a scope. A scope is collection of one or more physical or logical resources (e.g., a folder and/or files) associated with a respective authorization policy. An application can use the scope to group resources, to map a user requested resource to a scope (e.g., when an application checks for user access), and so on. The following is an exemplary syntax to define a scope: <AzScope Guid=“ce010982-6b6f-4e93-804e-d04bf1ddff78” Name=“Site Access for “User1””/>. Each scope has a unique identifier (e.g., ce010982-6b6f-4e93-804e-d04bf1ddff78) and a name (e.g., Site Access for “User1”) that can be used with an Application Programming Interface (API) to access the scope. For purposes of discussion, the illustrated scope has a metabase site ID of “w3svc/1”.
A role is defined when at least one (1) task has been specified with respect to an application group having access to a scope to which the role belongs. A task is one or more low-level operations to perform some unit of work for an administrator. For instance, a task might be “Change Password.” A task can encapsulate one or more other tasks. For example, a task called “Manage User Accounts” may include tasks “Change Password,” “Reset Password,” “Disable Account,” and/or so on. TABLE 3 shows an example role definition.
The role shown in TABLE 3 includes an AppMemberLink attribute that references an application group based on its unique identifier, in this example, bf9d00f0-2be3-4367-a931-680038b51d0a. TABLE 4 shows a scope with a related role.
A role may define one or more tasks. A task consists of one or more low-level “operations” that the user is given permission to perform, together with a business rule. An operation is a low-level permission that identifies security level(s) associated with a task. Several operations may comprise a meaningful task. Examples of operations include “WriteAttributes” and “ReadAttributes”. The following example of TABLE 5 illustrates a task allowing a user to change a property (e.g., the “DefaultDoc” property) for a Web site. The task contains two operations: one to set the value of this property, and one to get the value of this property.
In the example of TABLE 5, an operation is assigned a unique identifier and a name, as is the case with the definitions of the previous attributes. One of the most important characteristics of an operation is the OperationID attribute. A task can refer to one or more operations through the OperationID. TABLE 6 illustrates how to define an exemplary task.
The example of TABLE 6 shows two operations that are referenced by one task. This is to illustrate how a policy file can be defined. It is possible to have a task that refers to multiple operations. In one implementation, however, to ensure that the IIS Delegated Administration framework works as expected, within a policy file used with the tool, a task references only one operation. In such an implementation, when an operation is referenced by a task inside a role, the operation is not referenced by a different task inside the same role. Note, however, that the operation can be referenced by a task that is inside another role. For more information on exemplary syntax of the authorization policy store, see TABLE 11, below.
A task is defined one or more operations (e.g., the two operations defined in TABLE 6) identified by their unique IDs, and a business rule, or BizRule. A business rule is also called an authorization script written in a scripting language such as Jscript or VBScript. In this implementation, scripts that are attached to a task object that is run when an AccessCheck API is called to verify that the user can execute a given method. In this implementation, the AccessCheck API is implemented by a known Private Object Security (POS) API of an operating system 158 (FIG. 1). The POS API looks at a user's group memberships in a token and compares them to contents of an Access Control List (ACL) to determine if the user has the requested access. Scripts may use information that is available only at run time, such as “time of day” or “dollar amount requested,” to make an authentication decision.
For compliancy with the Authorization Manager 202, Delegated Administration (DA) module 204 uses one set of input values when interfacing with the Authorization Manager 202 and another set of values that are the parameters for the operation that the user wants to perform with respect to a hosted resource (e.g., a Web site) via a requesting application (e.g., the Remote Client Web Site Administration Application 208). For instance, in the preceding example of TABLE 6, for the SetDefaultDoc operation, the DA 204 utilizes as input the scope name, the operation or method name, and a value that is the value of the DefaultDoc parameter referred to in the BizRule above.
The DA 204 uses configuration file 218 to determine which Authorization Policy Store(s) 214 contains the input scope and to map the input operation or method name to an OperationID. In this implementation, the configuration file 218 is an XML file that specifies/defines each method assigned to a given set of users and maps the method to the corresponding operation identifier(s) (IDs) in the authorization policy store 214. The configuration file 218 also includes method parameters, scope mappings, log file data format, and command-line templates. When mapping scope name, DA 204 obtains from the configuration file 218 the path of the authorization policy store 214 where the scope is located, and the name of the application in this authorization policy store under which the scope is defined.
After the DA 204 parses the configuration file for such information, the DA 204 initializes the Authorization Manager 202 using the store path, opens the desired application, and gets the client context object that will be used to call determine whether the user has access to the requested function/resource.
IIS Delegated Administration Framework uses a registry entry of type “String” to store the full path to the configuration file 218 (e.g., HKLM\Software\Entity\IISDelAdmin\DelegAdminMappingPath (REG_SZ)). Such a string is stored in registry 220. TABLE 7 shows an exemplary configuration file 218.
In this exemplary implementation, the configuration file 218 includes the following entries: an entry for each method that will be allowed for a user; an entry for each scope, used in a store that contains a task referring to an existing method in the configuration file 218. Each scope entry corresponds to a user that has a scope in an authorization policy store. Additionally, an entry defines desired and/or default log file data format.
In this implementation, all of the attributes except Description are utilized. If an attribute is missing from a node definition to be used by ExecuteMethod, the method will return an error. (ExecuteMethod is an APi 222 exposed by the DA module 204 to performs an operation requested by the user—if authorized).
PublicName—The method name as it will be exposed to the user, the name that the tool will validate as an entry (a parameter of the ExecuteMethod method of a Dynamic Link Library object (e.g., a COM) accessed via API 222, exposed by the DA module 204).
ExePath—Defines either the path to the executable or command-line script that will be used to execute the method requested by the user or the ProgID of a COM object that is designated to perform the operation through one of its methods.
AZStoreID—Defines the OperationID that corresponds to this method in the authorization policy store.
CmdLine—Defines the way the command line for the executable module will be built, or the name of the method if ExePath specifies the ProgID of a COM object. For an executable module, in this attribute one can specify a keyword, an attribute name/value (method, parameter, and scope attributes) and a parameter index. For more information about defining CmdLine values, see the CmdLine Field Format below.
WaitTimeout—Indicates to the DA 204 how many seconds to wait after calling a CreateProcess API before exiting and logging the result. After a successful call to CreateProcess, the tool calls WaitForSingleObject (processHandle, timeout) to wait for that process to finish. This attribute is not used if the operation is associated with a COM method.
ProcessType—Specifies the type of process to be used to execute the method. The valid values for this attribute are “COM” (to specify that a COM method will execute the method) and “CMD” (to specify that a command-line executable will execute the method).
Separator—Assists in making the output of the executable module more granular. For special characters (such as “\r” and “\n”), this field includes the escaped version of the character (for example, “%0D” and “%0A”). The tool always reads the value of the Separator field and then unescapes it, so one can specify these special characters to be recognized as separators by the tool. For example, suppose a result will be a string containing a set of IP addresses that are denied for a site, and also that the result is a string containing all of these addresses separated by a “CRLF”(“\r\n” sequence). If the Separator=“%0D%0A” is defined in the IISDAMethod node, instead of the OutputArray function returning the whole string with the IP addresses, the function returns an array of strings, each corresponding to an IP address from the result string.
Description—Adds a description of the method, which can be used in the application that exposes the method to the user. For example, it is used by the sample ASP.NET application, Admin, to display the description of the method when the user moves the mouse over a method name on the page.
If a Parameter XML tag is defined, all of the attributes except Description are utilized. If one attribute is missing from a definition of the node and the node will be used by ExecuteMethod, the method will return an error.
Name—Sent by the tool as a parameter to the AccessCheck function. The same name is be used in the BizRule of the tasks that reference the operation ID corresponding to the method where the parameter is defined.
MetabaseProperty—Can be used if the execution module will request a specific metabase property as part of its command line, for example: “adsutil.exe get w3svc/1/AnonymousUserName”. In this example, the parameter has the attribute MetabaseProperty=“AnonymousUserName” and “w3svc/1” is the MetabaseNode defined in the scope. For more information about defining a scope, see Scope Syntax below.
Description—Associates a description with the parameter. For example, an application exposing the method to which such a parameter belongs to can use this field to display restrictions imposed on the parameter values.
One can specify the interfaces that will be used to execute a BizRule inside of a task that refers to an operation by using the Interface node. The following example shows the syntax of the Interface node: <Interface Name=““Flag=” “ProgID=””/>. Interface nodes are optional, and are used when COM objects are used in the business rule of a task, which references the method. If the Interface node is defined, all of the attributes are utilized. If one attribute is missing from the node definition and the node will be used by ExecuteMethod, the method will return an error.
Name—Identifies the name of the object as it is going to be used in the business rule.
Flag—Specifies the flag that will be used to create the object in the BizRule script.
ProgID—Specifies the independent version ProgID of the COM object. The corresponding Name in this node is, in fact, an instance of this object. The BizRule uses the object only through the Name provided.
Each attribute corresponds to a parameter utilized by AccessCheck related to interfaces.
<IISDAScope PublicName=““AZName=” “MetabaseNode=” “AZStorePath=” “AZApplicationName=” “GenerateAudits=” “AuditName=””/>.
All of the attributes are utilized. If one is missing and the node will be used by ExecuteMethod, the method will return an error.
PublicName—the name provided to the user when the scope is created, and the name the user will provide to identify at what level in the metabase 212 the changes are made (because a user can have more than one site assigned, for example).
AZName—the name of the scope in an authorization policy store file that corresponds to this scope. The MetabaseNode defines the actual scope, which is, in fact, a metabase node where the user has access.
AZStorePath—the path of the authorization policy store where this scope are located. This attribute specifies the authorization policy store where the DA module 204 will search for this scope.
AZApplicationName—specifies the application, in the store, under which this scope is defined.
GenerateAudits—specifies whether an attempt to access this scope generates auditing.
AuditName—specifies the key string used in auditing to identify the object that was accessed (in this implementation, it confirms that this scope, in particular, was accessed).
Path—defines the path where the log file is stored. This attribute is utilized.
The tool returns an error if it is not present. This attribute value points to a valid and accessible folder; otherwise, the tool of this implementation does not log anything, but will generate an exception. When creating the log file for the first time, the application uses the security settings inherited from the parent folder (identified by the value of the Path attribute), which means that the identity of the COM+ application (see, other module 210) has read/write access to this folder.
Field—identifies each field in the log file, using an associated Name attribute. For more information about fields, see Log File Fields below.
The result of the ExecuteMethod (ExecuteMethod is an APi 222 exposed by the DA module 204 to performs an operation requested by the user—if authorized. The operation or task implemented by ExecuteMethod is shown as the Execution Module 208) is logged using the comma-separated values log format. In this implementation, if a logging section is not present in the configuration file 218, DA 202 does not log anything and throws an exception.
A date and time (Date field) of the request (call to ExecuteMethod).
A name of the user (User field; for example, if the ExecuteMethod is called inside an .aspx page, the name of the user to whom access to the .aspx page was granted will be logged).
A method name (Method field) provided by the caller.
A scope name (Scope field) provided by the caller.
A value of the ExePath attribute corresponding to the method (ProcessType attribute, which is an attribute of the method definition in the configuration file attribute).
A value of the CmdLine attribute corresponding to the method (CmdLine field).
Delegated Administration 204 also logs in the last two positions the result (Result field) of the ExecuteMethod function 208 and the exception information (Exception field). The exception information provides details on the context of the exception (that is, in which step of the method execution the exception occurred) and the exception code that was caught by the tool.
The sixth field, CmdLine, utilizes a special mention. In the case of an IISDAMethod node with ProcessType=“COM,” the value logged in this field is as it appears defined in the configuration file 218 in the CmdLine attribute. In the case of an IISDAMethod node with ProcessType=“CMD,” the value logged in this field will be either as it appears defined in the configuration file 218 in the CmdLine attribute or (in case the string refers to IISDACmdLineKeys) the value of the full command line of the executable module, if ExecuteMethod actually built the command line for the module before returning. This provides more information in the log file to help one figure out as many elements of a request as possible and to ease the troubleshooting process.
If there is no Field node defined, the DA module 204 logs, for example, the eight (8) fields mentioned above, and the IISDALog node is used only to get the log file path. Usually, the field name is in the form “Param1,” “Param2,” and so on, because, in addition to the above-mentioned fields that are logged by default, these are the other fields that one might find useful.
In this implementation, “Param” fields are logged after the first six fields described above. If the list of parameter values contains more elements than the actual number of Field/nodes in the IISDALog node, not all of the parameter values are logged. However, if there are fewer parameter values for a method than the number of Field nodes in the IISDALog node, the rest of the field values in the log entry will consist of a space (“ ”).
Name—Used in the command-line string as a key.
AttributeName—Specifies the name of an attribute inside the configuration file, under the IISDAMethod, IISDAScope, or Parameter nodes, to which the key refers. This attribute enables one to specify either the attribute name itself or the attribute value to which it refers.
The command-line template allows Delegated Administration 202 to support tokens inside the command-line definition for a method (the CmdLine attribute of the IISDAMethod node). Such tokens include for example, the tokens shown in TABLE 9.
In this implementation, because # and $ are used for building the command line, these characters are restricted in the sense that if there is a sequence of two of these characters (like #string# or $string$), the tool will try to find an IISDACmdLineKey node that has a Name attribute equal to “string.” This is an implantation dependent feature that can be modified as design architecture implies.
This technique of defining the command-line parameters enables one to specify environment variables, such as % SYSTEMROOT %, in the module command line. When an IISDACmdLineKey node is created, all attributes are utilized. Otherwise, ExecuteMethod will fail when trying to parse the node. For more information about defining IISDACmdLineKey nodes and how they are interpreted at run time, see CmdLine and IISDACmdLineKeys Examples.
Parameters Method—sets the parameters associated with an operation. The parameters of this method is be a variant of type VT_ARRAY (where each element in the array is be of type VT_BSTR) or of type VT_BSTR. This method is called before calling ExecuteMethod.
ParamError Method—checks whether the parameters were set correctly by the Parameters method. If the parameters were set successfully, it returns 0. Call this method to avoid calling ExecuteMethod if parameters were not set correctly by the Parameters method.
Scope name—the scope associated with the user that is requesting the execution of the operation. The application that exposes the methods to the user collects this scope from the user. For example, using the sample ASP.NET application, the user specifies the name of the site to administer. This name is stored as a session variable and used whenever ExecuteMethod is invoked. The type of the parameter is BSTR.
Method name—the name of the method that the user will try to execute. This name corresponds to the value of a PublicName attribute of an IISDAMethod node inside the configuration file. The type of the parameter is BSTR.
LogResult—Boolean value specifying whether the method is to log the result of the operation.
ExecuteOperation—Boolean value specifying whether ExecuteMethod executes the command line or calls the COM method associated with the method. This parameter is useful when one want to use ExecuteMethod up to the point where AccessCheck decides whether the user is granted access to execute the method. If one choose not to execute any method or command line (by setting this parameter to FALSE), one can leave the values of the corresponding attributes of the IISDAMethod node as empty strings. After AccessCheck returns, the result is logged.
FIG. 3 shows an exemplary procedure 300 for delegated administration of a Web site. In particular, the procedure illustrates exemplary processing that occurs when a user attempts to modify properties of a Web site, wherein the Web site is hosted by an ISP that implements the described IIS Delegation Administration Framework of FIGS. 1 and 2. Accordingly, and for purposes of illustration, the operations of the procedure are described with respect to the features of FIGS. 1 and 2. As noted above, in the figures, the left-most digit of a component reference number identifies the particular figure in which the component first appears.
At block 302, an administrative entity (e.g., a member of the Administrative group) provides one or more parameters for an operation with respect to an application and/or resources hosted by computer 130 (FIG. 1). Such provision is provided via the API 216 exposed by the Authorization Module 202 (FIG. 2).
At block 304, a user executes an application such as the Remote Web Site Administration (RWSA) application 206 (FIG. 2) hosted by the computer 130 (FIG. 1). The RWSA application 206 allows a user, such as a Web site owner, to modify, test, or otherwise administer content and/or functionality, or any other aspect of a Web site or resource hosted by the computer 130 (FIG. 1). As described below, authorization for such administration is dynamically determined by the Delegation Administration (DA) module 204. For purposes of this example, the user is not a member of an Administrator group with respect to administering the configuration and/or resources associated with the computer 130 of FIG. 1, although the user could be a member of such an Administrators group. At block 306, the user requests to perform at least an operation with respect to the hosted resource (e.g., Web site, etc.). To this end, the application (e.g., the RWSA application 206) invoke one or more of the APIs 222 exposed by the Delegation Administration (DA) module 204, to requests access to the operation. As already noted, user operation access to a hosted resource is controlled by several layers of functionality, as shown in TABLE 10.
TABLE 11, an exemplary Authorization Manager Policy Store.
command-line module or a COM method.
At block 308, the Delegated Administration module 204, determines whether the user is authorized to access the resource via the requested operation. This determination is made completely independent of whether the user is a member of an Administrators group with respect to administering the resources of computer 130 (FIG. 1). To this end, the DA module 204, via the Parameters method API 222, sets ExecuteMethod parameters. ExecuteMethod looks for an entry in registry 220 providing the path to the configuration file 218. The configuration file 218 specifies all possible methods that can be performed by all of the users and where an administrative entity can add an entry (that is, an IISDAScope node) for each user.
At this point, at block 306, ExecuteMethod reads the configuration file 218 and attempts to map the requested operation name, scope, and parameters to entries in that file. If these entries are found, the information related to the authorization policy store 214 (i.e., derived from the IISDAScope node attribute) is retrieved. The ExecuteMethod retrieves the information from the Authorization Policy Store 214 and verifies (e.g., a call to AccessCheck) whether the user has access to the specified scope, based on the method and provided parameters. To accomplish this, ExecuteMethod impersonates the caller to present a client's identity to resources it hosts on the client's behalf, for access checks or authentication to be performed against the client's identity. (Impersonation is the ability of a thread to execute in a security context different from that of the process owning the thread).
At block 310, if the user is determined to not be authorized to perform the requested operation, the user is denied access to the operation. However, at block 312, if the user is granted access to the scope and if the method referred to is in a task within the user's scope, ExecuteMethod executes a process (i.e., Authorized Process 210) or builds a Command Line 210 to execute a process that performs the user requested operation (i.e., execute via an object (e.g., a COM object) or Command Line).
For instance, the DA module 202 either builds the command line for the executable module that will actually execute the operation/method, or attempts to initialize a COM object associated with the operation and get the DISPID of the specified method. Then, DA module 202 calls either CreateProcess or the COM method associated with the operation, depending on what is specified in the first Boolean parameter. In the case of CreateProcess, DA module 202 uses the command line 210 just built and the process starts under the user context of an application (e.g., a COM application). For purposes of discussion, such an application is shown as Authorized Process 210.
At block 314, if the requested operation runs successfully, the authorized process 210 builds an output array and logs the output array to the log file 224. For purposes of discussion, such an output array is shown as a respective portion of “other data” 226. In this implementation, if the return type of the method is VT_BSTR or VT_ARRAY, all of the elements in the array are of type VT_BSTR.
TABLE 11 shows an exemplary format of the Authorization Policy Store 214. For more information about the syntax of this type of file, see Authorization Policy Store File Format.
The following examples show how a command line is built for a module, based on the settings in a configuration file 218 and the parameters passed to the ExecuteMethod and Parameters methods.
The following example shows exemplary syntax of a configuration file 218 from which the exemplary command line of TABLE 11 is derived.
In view of the above, the following actions take place to produce this command line: “SET” is used as it is because it is not delimited by # or $ characters; #mn# is replaced by “w3svc/1”; “/” is used as it is because it is not delimited by # or $ characters” #mp@1# is replaced by “AccessFlags”; and, #1# is replaced with the value of the parameter of index 1, which is 3.
The following example shows exemplary syntax of a configuration file 218 from which the exemplary command line of TABLE 12 is derived.
In summary, the following actions take place to produce this command line: “SET” is used as it is because it is not delimited by # or $ characters; $mn$ is replaced by “MetabaseNode”; #mp@1# is replaced by “AccessFlags”; and, #1# is replaced with the value of the parameter of index 1, which is 3.
The following example shows configuration file syntax from which the command line of TABLE 12 is derived.
The following parameters are passed to ExecuteMethod: (“Scope1”, “SetFlags”). The following parameters are passed to Parameters: An array containing the following strings: “1”, “1”, “1”. Refer to the configuration file syntax to understand the following discussion of how this command line is built. The value of the CmdLine attribute of the method is “SET #1# #2# #3#.” The tool looks at the first sequence delimited by two # or $ characters, in this example #1#. Because there is a number between the two # characters, the tool replaces this token with the value of the first parameter. The tool performs the same procedure for the next two tokens: #2# and #3#.
The following example shows a command line that causes an error by providing an incorrect number of parameter to the Parameters method. Configuration file syntax from which the command line of TABLE 14 is derived follows.
The following parameters are passed to ExecuteMethod: (“Scope1”, “SetFlags”). The following parameters are passed to Parameters: An array containing the following strings: “1”, “1”, “1”.
In this example, the Delegation Administration module 202 returns an error because the command line refers to a parameter with index 4 (by specifying #4# in the CmdLine attribute), but Parameters receives only three parameters. Accordingly, no command line is built.
In the example of TABLE 15, this method corresponds to a method with OperationID=1 in the authorization policy store 214. The path of the executable or command line 210 that performs the requested action is “C:\Adsutil.exe.” The command-line template for this method is “SET #mn# #1#”. The time-out for this method to be executed is 10 seconds. No separator or description is defined. The method has only one parameter, named “Flags,” which corresponds to the “AccessFlags” property in the IIS metabase. The method defines the “MyObject” object name (corresponding to an instance of the “Scripting.FileSystemObject” object) as being able to be used by the BizRule associated with the task that refers to the operation with ID 1 in the authorization policy store.
In the example of TABLE 15, the scope, defined as “www.fabrikam.com”, corresponds to the scope named “Scope1” in the store located at “C:\Store.xml.” This scope inside this store is defined under the “SecurityApplication” application. Access to this scope generates an audit using the “Scope1” name to identify the entry in the EventLog.
This template specifies that the CmdLine attribute of the “SetProperty” method can use (beside “keywords” and #D# tokens for the parameter values) only tokens that include the “mn” key, which identifies by name (using $mn$) or by value (using #mn#) the attribute with the name “MetabaseNode” defined under the “IISDAScope,” corresponding to the scope specified as a parameter to ExecuteMethod.
The following assumptions apply to this exemplary scenario: The registry entry HKLM\Software\Microsoft\IISDelAdmin\DelegAdminMappingPath (REG_SZ) is defined and contains the following string: “C:\DelegAdmin\Config\Config.xml”—the configuration file 218. The Delegadm.dll object runs inside a COM+ application (i.e., the authorized process 210) whose identity has read access to this registry entry.
This code will attempt to allow user1 to set the AccessFlags property to 1 for the site corresponding to “ScopeUser1” by calling the “SetAccessProperty” method and using the Authorization Manager APIs.
To accomplish this task, the following steps are performed inside ExecuteMethod: The specified parameters are validated. As noted in “Parameters” method syntax, a parameter for the Parameters method can be either a string or an array of strings. In this example, the parameter is accepted, because it is a string. If the parameter is rejected, the corresponding error code is logged. The object attempts to get the value of the registry entry HKLM_Software_Microsoft_IISDelAdmin_DelegAdminMappingPath. In this example, the value is defined as C:\DelegAdmin\Config\Config.xml. The identity of the COM+ application has access to this value. If the application cannot read the registry entry value, it logs an error.
Because the operation was not executed, the CMDLine field in the log file will contain the value of the CmdLine attribute of the IISDAMethod node that corresponds to the SetAccessProperty method.
After the application gains access to the configuration file, it searches the configuration file for the scope “ScopeUser1,” which is specified as a parameter. If the scope is not found, an error is logged. An error may appear even if there is an “IISDAScope” node that contains the PublicName attribute with value “www.fabrikam.com” if this node does not have all of the utilized attributes.
After the public scope name is validated, the method name is validated. The application looks for the specified method name in the configuration file 118, which is “SetAccessProperty” in this example. If the method is not found, the appropriate error code is logged. An error may appear even if there is an “IISDAMethod” node that contains the PublicName attribute with value “SerAccessProperty” if this node doesn't have all of the utilized attributes.
After the method name is found, the corresponding IISDAMethod node is read. The tool now maps the “SetAccessProperty” method to the operation defined in the AZStoreID attribute, which in this example is “1.” As specified in syntax of the policy file, only one task in the authorization policy store can refer to this method. If more than one task in the authorization policy store refers to this method, AccessCheck may deny the access to the scope. This may occur because the business rule on one of the tasks has denied the access to the scope.
Along with the attributes, the subnodes of the IISDAMethod node are read to retrieve information about the parameters of the method and the interfaces that will be used in the business rule of the task that refers to this operation (in this example, the operation with ID “1”). If an error occurs in the validation process, a corresponding error code is logged. An error can occur because utilized attributes inside the Parameter or Interface subnodes are missing from the definition of the IISDAMethod node. The number of parameters defined in the configuration file matches the number of parameters that are set before ExecuteMethod is called (using the Parameters method). Otherwise, a specific error code is logged.
The application attempts to initialize the Authorization Store object using the store path, which in this example is “C:\DelegAdmin\Stores\User1.xml” and to open the corresponding application inside this store, which in this example is “SiteAdminApp.” If one of the operations fails, the exception is caught and the result will be logged.
The application collects information about the caller (which in this example is user1) and builds the parameters for AccessCheck. The following TABLE 16 describes the AccessCheck parameters used in this example.
of this parameter for AccessCheck.
are interested in, which in this example is 1.
Flags attribute in the Interface subnode, which is 9600.
cannot be created, a specific error code is returned.
If the process of building the parameters for AccessCheck succeeds, the function is called and the result is checked. In this example, the user1 is granted access to the “Scope1” scope based on the parameters and the two XML files defined. If this function fails, an exception is generated. If AccessCheck denies access to the user, a specific error code is logged.
In general, if an error occurs while building the command line (for example, if invalid sequences, such as defining a key as #KEY$, were used, or if undefined keys were used), the application logs an error.
The described systems and methods for generating a contrast-based saliency map for image attention analysis. Although the systems and methods have been described in language specific to structural features and methodological operations, the subject matter as defined in the appended claims are not necessarily limited to the specific features or operations described. Rather, the specific features and operations are disclosed as exemplary forms of implementing the claimed subject matter.
determining whether to authorize the operation as a function of whether the user has been delegated authority to perform the operation with respect to the resource, the authority being independent of whether the user is a member of an administrators group associated with any resource of the server.
2. A method as recited in claim 1, wherein determining whether to authorize the operation is performed by a secure delegation administration framework.
3. A method as recited in claim 1, wherein the operation is associated with modification of content and/or functionality of the resource.
4. A method as recited in claim 1, wherein the resource is represented as an Internet Information Service (IIS) metabase node.
5. A method as recited in claim 1, wherein the request comprises a scope associated with the user, and a name of a method associated with the operation.
6. A method as recited in claim 1, wherein the resource is a Web site hosted by an Internet Service Provider (ISP), and wherein the user is not authorized to perform administrative activities on any resources associated with the ISP except by sending the request to the ISP for permission evaluation by the secure delegation administration framework.
7. A method as recited in claim 1, wherein the request further comprises an indication of whether the user desires to execute the operation via a dynamically built command line or via an executable object already associated with the operation.
8. A method as recited in claim 1, wherein the request further comprises an indication of whether the user desires to log a result of the operation.
9. A method as recited in claim 1, wherein the secure delegation administration framework is secure at least because it does not allow the user access to a mapping of user role-based permission to perform the operation directed to the resource.
wherein determining further comprises the application utilizing the mapping to identify whether the user has permission to perform the operation.
responsive to the presenting, identifying whether the user has been delegated a role-based access permission to perform the operation with respect to the resource.
executing the operation within a scope associated with the user.
determining whether to authorize the operation as a function of whether the user has been delegated a role-based scope of authority to perform the operation, the role-based scope of authority not requiring the user to be a member of an administrators group associated with any resources of the server.
14. A computer-readable medium as recited in claim 13, wherein the operation is associated with modification of content and/or functionality of the resource.
15. A computer-readable medium as recited in claim 13, wherein the resource is represented as an Internet Information Service (IIS) metabase node.
16. A computer-readable medium as recited in claim 13, wherein the request comprises a scope associated with the user, and a name of a method associated with the operation.
17. A computer-readable medium as recited in claim 13, wherein the resource is a Web site hosted by an Internet Service Provider (ISP), and wherein the user is not a member of the administrators group.
18. A computer-readable medium as recited in claim 13, wherein the request further comprises an indication of whether the operation is to be executed via a dynamically built command line or via an executable object already associated with the operation.
19. A computer-readable medium as recited in claim 13, wherein operations associated with determining whether to authorize the operations are secure at least because the user does not have access to user role-based permission(s) to perform the operation.
wherein the instructions for determining further comprise instructions for utilizing the mapping to identify whether the user has permission to perform the operation.
determining whether to authorize the operation as a function of whether the user has been delegated a role-based scope of authority to perform the operation, the role-based scope of authority not requiring the user to be a member of an administrators group associated with resources of the server.
24. A server as recited in claim 23, wherein the request is generated by at least one resource of the resources.
25. A server as recited in claim 23, wherein the operation is associated with modification of content and/or functionality of the resource.
26. A server as recited in claim 23, wherein the resource is represented as an Internet Information Service (IIS) metabase node.
27. A server as recited in claim 23, wherein the request comprises a scope associated with the user, a name of a method associated with the operation.
28. A server as recited in claim 23, wherein the resource is a Web site hosted by an Internet Service Provider (ISP), and wherein the user is not a member of the administrators group.
29. A server as recited in claim 23, wherein the request further comprises an indication of whether the operation is to be executed via a dynamically built command line or via an executable object already associated with the operation.
30. A server as recited in claim 23, wherein the secure delegation administration framework is secure at least because it does not allow the user access to a mapping of user role-based permission to perform the operation directed to the resource.
means for determining whether to authorize the operation as a function of whether the user has been delegated a role-based scope of authority to perform the operation, the role-based scope of authority not requiring the user to be a member of an administrators group associated with the server.
35. A server as recited in claim 34, wherein the operation is associated with modification of content and/or functionality of the resource.
36. A server as recited in claim 34, wherein the resource is an Internet Information Service (IIS) metabase node.
37. A server as recited in claim 34, wherein the resource is a Web site hosted by an Internet Service Provider (ISP), and wherein the user is not a member of the administrators group.
means for executing the operation within a scope associated with the user.
MXPA04007143A MXPA04007143A (en) 2003-08-28 2004-07-23 Delegated administration of a hosted resource.
GB2353875A (en) 1999-09-04 2001-03-07 Hewlett Packard Co Computer access control system.

lowercased:
systems and methods for delegating access to resources hosted in a distributed computing environment are described. in one aspect, a server hosts a set of resources. the server receives a request from a user to perform an operation with respect to one of the hosted resources. responsive to receiving the request, the server determines whether the user has already been delegated authority to perform the operation. the delegated authority is independent of whether the user is a member of an administrators group associated with any resource of the server.
this patent application is related to u.s. patent application ser. no. 10/281,083, titled “role-based authorization management framework”, filed on oct. 26, 2002, commonly assigned to the assignee hereof and hereby incorporated by reference.
the invention pertains to administration of network service provider hosted resources.
administrating web sites can be time consuming and costly, especially for entities that manage large internet service provider (isp) installations. to save time and money, many isps support only large company web sites, at the expense of personal web sites. one reason for this is because computer security has become increasingly important not only to businesses and other organizations, but also to individuals. to meet such security needs, computer and web site security strategies must be selected and enforced for each administrative scenario. such selection and enforcement make it considerably labor and time intensive and expensive to support personal web sites.
fig. 1 shows an exemplary computing environment within which systems and methods for delegating administration of a hosted resource may be implemented.
fig. 2 shows further exemplary aspects of system memory of fig. 1, including application programs and program data for delegating administration of a hosted resource.
fig. 3 shows an exemplary procedure for delegating administration of a hosted resource.
reliable, scalable, manageable, and secure systems and methods to delegate and implement remote administration of web sites are described. in particular, an internet service provider (isp) computer server administrator utilizes the following described internet information services (iis) delegation administration (da) framework to delegate specified web site administration tasks to authorized users for execution. such an authorized user may include, for example, a user that owns a personal web site hosted by an isp.
user authorization is determined in view of specified role-based access permission(s) to perform specified application operations associated with the hosted web site. this iis da framework obviates existing trends involving computer security, wherein personal web sites are not supported due to the inefficiencies of time and cost, as described above. one reason for this is because an administrator is not required to intervene (i.e., to ensure computer security and authorized access) every time a hosted personal web site is modified or tested. such modifications may include, for example, change of web site content/functionality such as deployment of a new application on the web site, etc.
these and other aspects of the systems and methods for delegated web site administration are now described in further detail.
fig. 1 illustrates an example of a suitable computing environment 120 on which the subsequently described systems, apparatuses and methods for delegating administration of a hosted resource may be implemented. exemplary computing environment 120 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of systems and methods the described herein. neither should computing environment 120 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in computing environment 120.
the drives and associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules, and other data for computer 130. although the exemplary environment described herein employs a hard disk, a removable magnetic disk 148 and a removable optical disk 152, it are appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (rams), read only memories (rom), and the like, may also be used in the exemplary operating environment.
a user such as an isp web site administrator may provide commands and information into computer 130 through input devices such as keyboard 166 and pointing device 168 (such as a “mouse”). other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, digital camera, etc. these and other input devices are connected to the processing unit 132 through a user input interface 170 that is coupled to bus 136, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (usb).
a monitor 172 or other type of display device is also connected to bus 136 via an interface, such as a video adapter 174. the monitor can be utilized, for example, to present a user interface (ui) associated with the described systems and methods to delegate web site administration, for example, by defining application access policies and rules as described below. in addition to monitor 172, personal computers typically include other peripheral output devices (not shown), such as speakers and printers, which may be connected through output peripheral interface 175.
depicted in fig. 1, is a specific implementation of a wan via the internet. here, computer 130 employs modem 178 to establish communications with at least one remote computer 182 via the internet 180. in a networked environment, program modules depicted relative to computer 130, or portions thereof, may be stored in a remote memory storage device. thus, e.g., as depicted in fig. 1, remote application programs 189 may reside on a memory device of remote computer 182. the network connections shown and described are exemplary. thus, other means of establishing a communications link between the computing devices may be used.
fig. 2 is a block diagram that shows further exemplary aspects of system memory 134 of fig. 1, including application programs 160 and program data 164 for delegating administration of a hosted resource. in this implementation, application programs 160 include, for example authorization module 202, delegation module 204, remote client web site administration (rcwa) module 206 (i.e., the “requesting application”), execution module 208, and authorized process(es) 210. for purposes of discussion, these application programs in conjunction with selected other features of the system 100 of fig. 1, are hereinafter often referred to as the “internet information services (iis) delegated administration (da) framework, or “framework”.
the authorization manager 202 provides security support for delegating administration of a hosted resource of iis metabase nodes (i.e., nodes of the iis metabase 212). the iis metabase 212 identifies nodes for applications, resources, or objects hosted, deployed, and/or managed by the computer 130 of fig. 1. more particularly, the metabase is a hierarchical store of configuration information and schema that are used to configure iis. in existing systems, only users who are members of the administrators group can view and modify a resource represented by a metabase node. in contrast to such conventional systems, the iis da framework, which is now being described, allows users other than those in the administrators group (e.g., application administrators) such as web site owners to view and/or modify particularly specified portion(s) of the iis metabase 212. for purposes of this description, a “user” is an individual that is not assigned to the administrative group, although a user could also be of the administrators group.
to this end, the authorization manager module 202, via selective interaction with the delegation administration (da) module 204, allows an administrative entity (i.e., a member of the administrators group) to specify (e.g., specify via a ui displayed on the display device 172 of fig. 1) user access permissions to nodes of the iis metabase 212. the authorization manager module 202 writes such user access permissions (i.e., policies/rules) to authorization policy store 214. in one implementation, such access permissions are represented, for example, in extended markup language (xml), active directory, software query language (sql), or some other data format.
an application queries the aps 214 (via api's 216 exposed by the application manager 202) at run time to confirm that a client is authorized to perform a requested operation on a resource. authorization manager provides apis for managing authorization policy and validating access control and a user interface for administrators so that they can manage the authorization policy store.
an application as specified by the authorization policy store (aps) 214 is a top-level node of the authorization policy store 214. an application specifies the operations or tasks that the application can perform and declares them in the aps 214, for instance, when the application is installed. an application specification includes administrator identified application specific roles in terms of the task and operations that are needed to perform a job (e.g., in an organization). the definitions of roles, tasks and operations (methods), and scopes are stored in the aps 214. a role is an authorization or resource configuration role (e.g., an organizational permission on some set of resources). an authorization role is based on a user's job function. a resource configuration role is based on a computer's function.
a task is a collection of low-level operations. the purpose of the task is to determine which low-level operations do some unit of work that is meaningful to administrators. an example of a task might be change password. tasks can also contain other tasks. for example, a task called manage user accounts may include the tasks change password, reset password, disable account, and so on.
an operation is a low-level permission that a resource manager uses to identify security procedures. several operations may be used to perform a meaningful task. (operations are often not exposed or meaningful to administrators). an example of an operation could be writeattributes or readattributes. a scope is collection of one or more physical or logical resources (e.g., a folder and/or files) associated with a respective authorization policy. an application can use the scope to group resources, to map a user requested resource to a scope (e.g., when an application checks for user access), and so on.
in this implementation, the authorization manager 202 allows specification of zero (0) or more groups and corresponding roles for each specified group member. a group corresponds to a user's role, and an application administrator specifies the permissions that are needed by the role by granting the group permission in an acl for an object (e.g., application, resource, etc.). table 1 shows an exemplary application definition of the aps 214, which in this implementation, is in an xml data format.
each application includes numerous attributes such as a substantially globally unique identifier (a “guid”, e.g., d9089f17-5fa6-4ae9-bddf-8ca6cd1c06fb), a name (e.g., siteadminapp), and so on. application attributes are used, for instance, to identify particular ones of the applications specified in the authorization policy store 214. in the example, of table 1, the application includes a group (e.g., see tag pair “azapplicationgroup”) to specify one or more users assigned to one or more “roles” with respect to the application. a role is a set of permissions assigned to a user to enable the user to perform a set of tasks. each application group includes a guid attribute (e.g., value bf9d00f0-2be3-4367-a931-680038b51d0a) and a name attribute (e.g., groupmetabasechangedefaultdoc). this exemplary group illustrates a single member identified by sid: s-1-5-21-3131233723-616130271-937215924-1032. for the purpose of this example, assume that this is the sid is associated with a user, “user1”.
in this implementation, a role is applied to a set of associated objects, and then a group of users is assigned to the role.
the application of table 1 includes an application group (although any number of such groups could be defined) with a scope. a scope is collection of one or more physical or logical resources (e.g., a folder and/or files) associated with a respective authorization policy. an application can use the scope to group resources, to map a user requested resource to a scope (e.g., when an application checks for user access), and so on. the following is an exemplary syntax to define a scope: <azscope guid=“ce010982-6b6f-4e93-804e-d04bf1ddff78” name=“site access for “user1””/>. each scope has a unique identifier (e.g., ce010982-6b6f-4e93-804e-d04bf1ddff78) and a name (e.g., site access for “user1”) that can be used with an application programming interface (api) to access the scope. for purposes of discussion, the illustrated scope has a metabase site id of “w3svc/1”.
a role is defined when at least one (1) task has been specified with respect to an application group having access to a scope to which the role belongs. a task is one or more low-level operations to perform some unit of work for an administrator. for instance, a task might be “change password.” a task can encapsulate one or more other tasks. for example, a task called “manage user accounts” may include tasks “change password,” “reset password,” “disable account,” and/or so on. table 3 shows an example role definition.
the role shown in table 3 includes an appmemberlink attribute that references an application group based on its unique identifier, in this example, bf9d00f0-2be3-4367-a931-680038b51d0a. table 4 shows a scope with a related role.
a role may define one or more tasks. a task consists of one or more low-level “operations” that the user is given permission to perform, together with a business rule. an operation is a low-level permission that identifies security level(s) associated with a task. several operations may comprise a meaningful task. examples of operations include “writeattributes” and “readattributes”. the following example of table 5 illustrates a task allowing a user to change a property (e.g., the “defaultdoc” property) for a web site. the task contains two operations: one to set the value of this property, and one to get the value of this property.
in the example of table 5, an operation is assigned a unique identifier and a name, as is the case with the definitions of the previous attributes. one of the most important characteristics of an operation is the operationid attribute. a task can refer to one or more operations through the operationid. table 6 illustrates how to define an exemplary task.
the example of table 6 shows two operations that are referenced by one task. this is to illustrate how a policy file can be defined. it is possible to have a task that refers to multiple operations. in one implementation, however, to ensure that the iis delegated administration framework works as expected, within a policy file used with the tool, a task references only one operation. in such an implementation, when an operation is referenced by a task inside a role, the operation is not referenced by a different task inside the same role. note, however, that the operation can be referenced by a task that is inside another role. for more information on exemplary syntax of the authorization policy store, see table 11, below.
a task is defined one or more operations (e.g., the two operations defined in table 6) identified by their unique ids, and a business rule, or bizrule. a business rule is also called an authorization script written in a scripting language such as jscript or vbscript. in this implementation, scripts that are attached to a task object that is run when an accesscheck api is called to verify that the user can execute a given method. in this implementation, the accesscheck api is implemented by a known private object security (pos) api of an operating system 158 (fig. 1). the pos api looks at a user's group memberships in a token and compares them to contents of an access control list (acl) to determine if the user has the requested access. scripts may use information that is available only at run time, such as “time of day” or “dollar amount requested,” to make an authentication decision.
for compliancy with the authorization manager 202, delegated administration (da) module 204 uses one set of input values when interfacing with the authorization manager 202 and another set of values that are the parameters for the operation that the user wants to perform with respect to a hosted resource (e.g., a web site) via a requesting application (e.g., the remote client web site administration application 208). for instance, in the preceding example of table 6, for the setdefaultdoc operation, the da 204 utilizes as input the scope name, the operation or method name, and a value that is the value of the defaultdoc parameter referred to in the bizrule above.
the da 204 uses configuration file 218 to determine which authorization policy store(s) 214 contains the input scope and to map the input operation or method name to an operationid. in this implementation, the configuration file 218 is an xml file that specifies/defines each method assigned to a given set of users and maps the method to the corresponding operation identifier(s) (ids) in the authorization policy store 214. the configuration file 218 also includes method parameters, scope mappings, log file data format, and command-line templates. when mapping scope name, da 204 obtains from the configuration file 218 the path of the authorization policy store 214 where the scope is located, and the name of the application in this authorization policy store under which the scope is defined.
after the da 204 parses the configuration file for such information, the da 204 initializes the authorization manager 202 using the store path, opens the desired application, and gets the client context object that will be used to call determine whether the user has access to the requested function/resource.
iis delegated administration framework uses a registry entry of type “string” to store the full path to the configuration file 218 (e.g., hklm\software\entity\iisdeladmin\delegadminmappingpath (reg_sz)). such a string is stored in registry 220. table 7 shows an exemplary configuration file 218.
in this exemplary implementation, the configuration file 218 includes the following entries: an entry for each method that will be allowed for a user; an entry for each scope, used in a store that contains a task referring to an existing method in the configuration file 218. each scope entry corresponds to a user that has a scope in an authorization policy store. additionally, an entry defines desired and/or default log file data format.
in this implementation, all of the attributes except description are utilized. if an attribute is missing from a node definition to be used by executemethod, the method will return an error. (executemethod is an api 222 exposed by the da module 204 to performs an operation requested by the user—if authorized).
publicname—the method name as it will be exposed to the user, the name that the tool will validate as an entry (a parameter of the executemethod method of a dynamic link library object (e.g., a com) accessed via api 222, exposed by the da module 204).
exepath—defines either the path to the executable or command-line script that will be used to execute the method requested by the user or the progid of a com object that is designated to perform the operation through one of its methods.
azstoreid—defines the operationid that corresponds to this method in the authorization policy store.
cmdline—defines the way the command line for the executable module will be built, or the name of the method if exepath specifies the progid of a com object. for an executable module, in this attribute one can specify a keyword, an attribute name/value (method, parameter, and scope attributes) and a parameter index. for more information about defining cmdline values, see the cmdline field format below.
waittimeout—indicates to the da 204 how many seconds to wait after calling a createprocess api before exiting and logging the result. after a successful call to createprocess, the tool calls waitforsingleobject (processhandle, timeout) to wait for that process to finish. this attribute is not used if the operation is associated with a com method.
processtype—specifies the type of process to be used to execute the method. the valid values for this attribute are “com” (to specify that a com method will execute the method) and “cmd” (to specify that a command-line executable will execute the method).
separator—assists in making the output of the executable module more granular. for special characters (such as “\r” and “\n”), this field includes the escaped version of the character (for example, “%0d” and “%0a”). the tool always reads the value of the separator field and then unescapes it, so one can specify these special characters to be recognized as separators by the tool. for example, suppose a result will be a string containing a set of ip addresses that are denied for a site, and also that the result is a string containing all of these addresses separated by a “crlf”(“\r\n” sequence). if the separator=“%0d%0a” is defined in the iisdamethod node, instead of the outputarray function returning the whole string with the ip addresses, the function returns an array of strings, each corresponding to an ip address from the result string.
description—adds a description of the method, which can be used in the application that exposes the method to the user. for example, it is used by the sample asp.net application, admin, to display the description of the method when the user moves the mouse over a method name on the page.
if a parameter xml tag is defined, all of the attributes except description are utilized. if one attribute is missing from a definition of the node and the node will be used by executemethod, the method will return an error.
name—sent by the tool as a parameter to the accesscheck function. the same name is be used in the bizrule of the tasks that reference the operation id corresponding to the method where the parameter is defined.
metabaseproperty—can be used if the execution module will request a specific metabase property as part of its command line, for example: “adsutil.exe get w3svc/1/anonymoususername”. in this example, the parameter has the attribute metabaseproperty=“anonymoususername” and “w3svc/1” is the metabasenode defined in the scope. for more information about defining a scope, see scope syntax below.
description—associates a description with the parameter. for example, an application exposing the method to which such a parameter belongs to can use this field to display restrictions imposed on the parameter values.
one can specify the interfaces that will be used to execute a bizrule inside of a task that refers to an operation by using the interface node. the following example shows the syntax of the interface node: <interface name=““flag=” “progid=””/>. interface nodes are optional, and are used when com objects are used in the business rule of a task, which references the method. if the interface node is defined, all of the attributes are utilized. if one attribute is missing from the node definition and the node will be used by executemethod, the method will return an error.
name—identifies the name of the object as it is going to be used in the business rule.
flag—specifies the flag that will be used to create the object in the bizrule script.
progid—specifies the independent version progid of the com object. the corresponding name in this node is, in fact, an instance of this object. the bizrule uses the object only through the name provided.
each attribute corresponds to a parameter utilized by accesscheck related to interfaces.
<iisdascope publicname=““azname=” “metabasenode=” “azstorepath=” “azapplicationname=” “generateaudits=” “auditname=””/>.
all of the attributes are utilized. if one is missing and the node will be used by executemethod, the method will return an error.
publicname—the name provided to the user when the scope is created, and the name the user will provide to identify at what level in the metabase 212 the changes are made (because a user can have more than one site assigned, for example).
azname—the name of the scope in an authorization policy store file that corresponds to this scope. the metabasenode defines the actual scope, which is, in fact, a metabase node where the user has access.
azstorepath—the path of the authorization policy store where this scope are located. this attribute specifies the authorization policy store where the da module 204 will search for this scope.
azapplicationname—specifies the application, in the store, under which this scope is defined.
generateaudits—specifies whether an attempt to access this scope generates auditing.
auditname—specifies the key string used in auditing to identify the object that was accessed (in this implementation, it confirms that this scope, in particular, was accessed).
path—defines the path where the log file is stored. this attribute is utilized.
the tool returns an error if it is not present. this attribute value points to a valid and accessible folder; otherwise, the tool of this implementation does not log anything, but will generate an exception. when creating the log file for the first time, the application uses the security settings inherited from the parent folder (identified by the value of the path attribute), which means that the identity of the com+ application (see, other module 210) has read/write access to this folder.
field—identifies each field in the log file, using an associated name attribute. for more information about fields, see log file fields below.
the result of the executemethod (executemethod is an api 222 exposed by the da module 204 to performs an operation requested by the user—if authorized. the operation or task implemented by executemethod is shown as the execution module 208) is logged using the comma-separated values log format. in this implementation, if a logging section is not present in the configuration file 218, da 202 does not log anything and throws an exception.
a date and time (date field) of the request (call to executemethod).
a name of the user (user field; for example, if the executemethod is called inside an .aspx page, the name of the user to whom access to the .aspx page was granted will be logged).
a method name (method field) provided by the caller.
a scope name (scope field) provided by the caller.
a value of the exepath attribute corresponding to the method (processtype attribute, which is an attribute of the method definition in the configuration file attribute).
a value of the cmdline attribute corresponding to the method (cmdline field).
delegated administration 204 also logs in the last two positions the result (result field) of the executemethod function 208 and the exception information (exception field). the exception information provides details on the context of the exception (that is, in which step of the method execution the exception occurred) and the exception code that was caught by the tool.
the sixth field, cmdline, utilizes a special mention. in the case of an iisdamethod node with processtype=“com,” the value logged in this field is as it appears defined in the configuration file 218 in the cmdline attribute. in the case of an iisdamethod node with processtype=“cmd,” the value logged in this field will be either as it appears defined in the configuration file 218 in the cmdline attribute or (in case the string refers to iisdacmdlinekeys) the value of the full command line of the executable module, if executemethod actually built the command line for the module before returning. this provides more information in the log file to help one figure out as many elements of a request as possible and to ease the troubleshooting process.
if there is no field node defined, the da module 204 logs, for example, the eight (8) fields mentioned above, and the iisdalog node is used only to get the log file path. usually, the field name is in the form “param1,” “param2,” and so on, because, in addition to the above-mentioned fields that are logged by default, these are the other fields that one might find useful.
in this implementation, “param” fields are logged after the first six fields described above. if the list of parameter values contains more elements than the actual number of field/nodes in the iisdalog node, not all of the parameter values are logged. however, if there are fewer parameter values for a method than the number of field nodes in the iisdalog node, the rest of the field values in the log entry will consist of a space (“ ”).
name—used in the command-line string as a key.
attributename—specifies the name of an attribute inside the configuration file, under the iisdamethod, iisdascope, or parameter nodes, to which the key refers. this attribute enables one to specify either the attribute name itself or the attribute value to which it refers.
the command-line template allows delegated administration 202 to support tokens inside the command-line definition for a method (the cmdline attribute of the iisdamethod node). such tokens include for example, the tokens shown in table 9.
in this implementation, because # and $ are used for building the command line, these characters are restricted in the sense that if there is a sequence of two of these characters (like #string# or $string$), the tool will try to find an iisdacmdlinekey node that has a name attribute equal to “string.” this is an implantation dependent feature that can be modified as design architecture implies.
this technique of defining the command-line parameters enables one to specify environment variables, such as % systemroot %, in the module command line. when an iisdacmdlinekey node is created, all attributes are utilized. otherwise, executemethod will fail when trying to parse the node. for more information about defining iisdacmdlinekey nodes and how they are interpreted at run time, see cmdline and iisdacmdlinekeys examples.
parameters method—sets the parameters associated with an operation. the parameters of this method is be a variant of type vt_array (where each element in the array is be of type vt_bstr) or of type vt_bstr. this method is called before calling executemethod.
paramerror method—checks whether the parameters were set correctly by the parameters method. if the parameters were set successfully, it returns 0. call this method to avoid calling executemethod if parameters were not set correctly by the parameters method.
scope name—the scope associated with the user that is requesting the execution of the operation. the application that exposes the methods to the user collects this scope from the user. for example, using the sample asp.net application, the user specifies the name of the site to administer. this name is stored as a session variable and used whenever executemethod is invoked. the type of the parameter is bstr.
method name—the name of the method that the user will try to execute. this name corresponds to the value of a publicname attribute of an iisdamethod node inside the configuration file. the type of the parameter is bstr.
logresult—boolean value specifying whether the method is to log the result of the operation.
executeoperation—boolean value specifying whether executemethod executes the command line or calls the com method associated with the method. this parameter is useful when one want to use executemethod up to the point where accesscheck decides whether the user is granted access to execute the method. if one choose not to execute any method or command line (by setting this parameter to false), one can leave the values of the corresponding attributes of the iisdamethod node as empty strings. after accesscheck returns, the result is logged.
fig. 3 shows an exemplary procedure 300 for delegated administration of a web site. in particular, the procedure illustrates exemplary processing that occurs when a user attempts to modify properties of a web site, wherein the web site is hosted by an isp that implements the described iis delegation administration framework of figs. 1 and 2. accordingly, and for purposes of illustration, the operations of the procedure are described with respect to the features of figs. 1 and 2. as noted above, in the figures, the left-most digit of a component reference number identifies the particular figure in which the component first appears.
at block 302, an administrative entity (e.g., a member of the administrative group) provides one or more parameters for an operation with respect to an application and/or resources hosted by computer 130 (fig. 1). such provision is provided via the api 216 exposed by the authorization module 202 (fig. 2).
at block 304, a user executes an application such as the remote web site administration (rwsa) application 206 (fig. 2) hosted by the computer 130 (fig. 1). the rwsa application 206 allows a user, such as a web site owner, to modify, test, or otherwise administer content and/or functionality, or any other aspect of a web site or resource hosted by the computer 130 (fig. 1). as described below, authorization for such administration is dynamically determined by the delegation administration (da) module 204. for purposes of this example, the user is not a member of an administrator group with respect to administering the configuration and/or resources associated with the computer 130 of fig. 1, although the user could be a member of such an administrators group. at block 306, the user requests to perform at least an operation with respect to the hosted resource (e.g., web site, etc.). to this end, the application (e.g., the rwsa application 206) invoke one or more of the apis 222 exposed by the delegation administration (da) module 204, to requests access to the operation. as already noted, user operation access to a hosted resource is controlled by several layers of functionality, as shown in table 10.
table 11, an exemplary authorization manager policy store.
command-line module or a com method.
at block 308, the delegated administration module 204, determines whether the user is authorized to access the resource via the requested operation. this determination is made completely independent of whether the user is a member of an administrators group with respect to administering the resources of computer 130 (fig. 1). to this end, the da module 204, via the parameters method api 222, sets executemethod parameters. executemethod looks for an entry in registry 220 providing the path to the configuration file 218. the configuration file 218 specifies all possible methods that can be performed by all of the users and where an administrative entity can add an entry (that is, an iisdascope node) for each user.
at this point, at block 306, executemethod reads the configuration file 218 and attempts to map the requested operation name, scope, and parameters to entries in that file. if these entries are found, the information related to the authorization policy store 214 (i.e., derived from the iisdascope node attribute) is retrieved. the executemethod retrieves the information from the authorization policy store 214 and verifies (e.g., a call to accesscheck) whether the user has access to the specified scope, based on the method and provided parameters. to accomplish this, executemethod impersonates the caller to present a client's identity to resources it hosts on the client's behalf, for access checks or authentication to be performed against the client's identity. (impersonation is the ability of a thread to execute in a security context different from that of the process owning the thread).
at block 310, if the user is determined to not be authorized to perform the requested operation, the user is denied access to the operation. however, at block 312, if the user is granted access to the scope and if the method referred to is in a task within the user's scope, executemethod executes a process (i.e., authorized process 210) or builds a command line 210 to execute a process that performs the user requested operation (i.e., execute via an object (e.g., a com object) or command line).
for instance, the da module 202 either builds the command line for the executable module that will actually execute the operation/method, or attempts to initialize a com object associated with the operation and get the dispid of the specified method. then, da module 202 calls either createprocess or the com method associated with the operation, depending on what is specified in the first boolean parameter. in the case of createprocess, da module 202 uses the command line 210 just built and the process starts under the user context of an application (e.g., a com application). for purposes of discussion, such an application is shown as authorized process 210.
at block 314, if the requested operation runs successfully, the authorized process 210 builds an output array and logs the output array to the log file 224. for purposes of discussion, such an output array is shown as a respective portion of “other data” 226. in this implementation, if the return type of the method is vt_bstr or vt_array, all of the elements in the array are of type vt_bstr.
table 11 shows an exemplary format of the authorization policy store 214. for more information about the syntax of this type of file, see authorization policy store file format.
the following examples show how a command line is built for a module, based on the settings in a configuration file 218 and the parameters passed to the executemethod and parameters methods.
the following example shows exemplary syntax of a configuration file 218 from which the exemplary command line of table 11 is derived.
in view of the above, the following actions take place to produce this command line: “set” is used as it is because it is not delimited by # or $ characters; #mn# is replaced by “w3svc/1”; “/” is used as it is because it is not delimited by # or $ characters” #mp@1# is replaced by “accessflags”; and, #1# is replaced with the value of the parameter of index 1, which is 3.
the following example shows exemplary syntax of a configuration file 218 from which the exemplary command line of table 12 is derived.
in summary, the following actions take place to produce this command line: “set” is used as it is because it is not delimited by # or $ characters; $mn$ is replaced by “metabasenode”; #mp@1# is replaced by “accessflags”; and, #1# is replaced with the value of the parameter of index 1, which is 3.
the following example shows configuration file syntax from which the command line of table 12 is derived.
the following parameters are passed to executemethod: (“scope1”, “setflags”). the following parameters are passed to parameters: an array containing the following strings: “1”, “1”, “1”. refer to the configuration file syntax to understand the following discussion of how this command line is built. the value of the cmdline attribute of the method is “set #1# #2# #3#.” the tool looks at the first sequence delimited by two # or $ characters, in this example #1#. because there is a number between the two # characters, the tool replaces this token with the value of the first parameter. the tool performs the same procedure for the next two tokens: #2# and #3#.
the following example shows a command line that causes an error by providing an incorrect number of parameter to the parameters method. configuration file syntax from which the command line of table 14 is derived follows.
the following parameters are passed to executemethod: (“scope1”, “setflags”). the following parameters are passed to parameters: an array containing the following strings: “1”, “1”, “1”.
in this example, the delegation administration module 202 returns an error because the command line refers to a parameter with index 4 (by specifying #4# in the cmdline attribute), but parameters receives only three parameters. accordingly, no command line is built.
in the example of table 15, this method corresponds to a method with operationid=1 in the authorization policy store 214. the path of the executable or command line 210 that performs the requested action is “c:\adsutil.exe.” the command-line template for this method is “set #mn# #1#”. the time-out for this method to be executed is 10 seconds. no separator or description is defined. the method has only one parameter, named “flags,” which corresponds to the “accessflags” property in the iis metabase. the method defines the “myobject” object name (corresponding to an instance of the “scripting.filesystemobject” object) as being able to be used by the bizrule associated with the task that refers to the operation with id 1 in the authorization policy store.
in the example of table 15, the scope, defined as “www.fabrikam.com”, corresponds to the scope named “scope1” in the store located at “c:\store.xml.” this scope inside this store is defined under the “securityapplication” application. access to this scope generates an audit using the “scope1” name to identify the entry in the eventlog.
this template specifies that the cmdline attribute of the “setproperty” method can use (beside “keywords” and #d# tokens for the parameter values) only tokens that include the “mn” key, which identifies by name (using $mn$) or by value (using #mn#) the attribute with the name “metabasenode” defined under the “iisdascope,” corresponding to the scope specified as a parameter to executemethod.
the following assumptions apply to this exemplary scenario: the registry entry hklm\software\microsoft\iisdeladmin\delegadminmappingpath (reg_sz) is defined and contains the following string: “c:\delegadmin\config\config.xml”—the configuration file 218. the delegadm.dll object runs inside a com+ application (i.e., the authorized process 210) whose identity has read access to this registry entry.
this code will attempt to allow user1 to set the accessflags property to 1 for the site corresponding to “scopeuser1” by calling the “setaccessproperty” method and using the authorization manager apis.
to accomplish this task, the following steps are performed inside executemethod: the specified parameters are validated. as noted in “parameters” method syntax, a parameter for the parameters method can be either a string or an array of strings. in this example, the parameter is accepted, because it is a string. if the parameter is rejected, the corresponding error code is logged. the object attempts to get the value of the registry entry hklm_software_microsoft_iisdeladmin_delegadminmappingpath. in this example, the value is defined as c:\delegadmin\config\config.xml. the identity of the com+ application has access to this value. if the application cannot read the registry entry value, it logs an error.
because the operation was not executed, the cmdline field in the log file will contain the value of the cmdline attribute of the iisdamethod node that corresponds to the setaccessproperty method.
after the application gains access to the configuration file, it searches the configuration file for the scope “scopeuser1,” which is specified as a parameter. if the scope is not found, an error is logged. an error may appear even if there is an “iisdascope” node that contains the publicname attribute with value “www.fabrikam.com” if this node does not have all of the utilized attributes.
after the public scope name is validated, the method name is validated. the application looks for the specified method name in the configuration file 118, which is “setaccessproperty” in this example. if the method is not found, the appropriate error code is logged. an error may appear even if there is an “iisdamethod” node that contains the publicname attribute with value “seraccessproperty” if this node doesn't have all of the utilized attributes.
after the method name is found, the corresponding iisdamethod node is read. the tool now maps the “setaccessproperty” method to the operation defined in the azstoreid attribute, which in this example is “1.” as specified in syntax of the policy file, only one task in the authorization policy store can refer to this method. if more than one task in the authorization policy store refers to this method, accesscheck may deny the access to the scope. this may occur because the business rule on one of the tasks has denied the access to the scope.
along with the attributes, the subnodes of the iisdamethod node are read to retrieve information about the parameters of the method and the interfaces that will be used in the business rule of the task that refers to this operation (in this example, the operation with id “1”). if an error occurs in the validation process, a corresponding error code is logged. an error can occur because utilized attributes inside the parameter or interface subnodes are missing from the definition of the iisdamethod node. the number of parameters defined in the configuration file matches the number of parameters that are set before executemethod is called (using the parameters method). otherwise, a specific error code is logged.
the application attempts to initialize the authorization store object using the store path, which in this example is “c:\delegadmin\stores\user1.xml” and to open the corresponding application inside this store, which in this example is “siteadminapp.” if one of the operations fails, the exception is caught and the result will be logged.
the application collects information about the caller (which in this example is user1) and builds the parameters for accesscheck. the following table 16 describes the accesscheck parameters used in this example.
of this parameter for accesscheck.
are interested in, which in this example is 1.
flags attribute in the interface subnode, which is 9600.
cannot be created, a specific error code is returned.
if the process of building the parameters for accesscheck succeeds, the function is called and the result is checked. in this example, the user1 is granted access to the “scope1” scope based on the parameters and the two xml files defined. if this function fails, an exception is generated. if accesscheck denies access to the user, a specific error code is logged.
in general, if an error occurs while building the command line (for example, if invalid sequences, such as defining a key as #key$, were used, or if undefined keys were used), the application logs an error.
the described systems and methods for generating a contrast-based saliency map for image attention analysis. although the systems and methods have been described in language specific to structural features and methodological operations, the subject matter as defined in the appended claims are not necessarily limited to the specific features or operations described. rather, the specific features and operations are disclosed as exemplary forms of implementing the claimed subject matter.
determining whether to authorize the operation as a function of whether the user has been delegated authority to perform the operation with respect to the resource, the authority being independent of whether the user is a member of an administrators group associated with any resource of the server.
2. a method as recited in claim 1, wherein determining whether to authorize the operation is performed by a secure delegation administration framework.
3. a method as recited in claim 1, wherein the operation is associated with modification of content and/or functionality of the resource.
4. a method as recited in claim 1, wherein the resource is represented as an internet information service (iis) metabase node.
5. a method as recited in claim 1, wherein the request comprises a scope associated with the user, and a name of a method associated with the operation.
6. a method as recited in claim 1, wherein the resource is a web site hosted by an internet service provider (isp), and wherein the user is not authorized to perform administrative activities on any resources associated with the isp except by sending the request to the isp for permission evaluation by the secure delegation administration framework.
7. a method as recited in claim 1, wherein the request further comprises an indication of whether the user desires to execute the operation via a dynamically built command line or via an executable object already associated with the operation.
8. a method as recited in claim 1, wherein the request further comprises an indication of whether the user desires to log a result of the operation.
9. a method as recited in claim 1, wherein the secure delegation administration framework is secure at least because it does not allow the user access to a mapping of user role-based permission to perform the operation directed to the resource.
wherein determining further comprises the application utilizing the mapping to identify whether the user has permission to perform the operation.
responsive to the presenting, identifying whether the user has been delegated a role-based access permission to perform the operation with respect to the resource.
executing the operation within a scope associated with the user.
determining whether to authorize the operation as a function of whether the user has been delegated a role-based scope of authority to perform the operation, the role-based scope of authority not requiring the user to be a member of an administrators group associated with any resources of the server.
14. a computer-readable medium as recited in claim 13, wherein the operation is associated with modification of content and/or functionality of the resource.
15. a computer-readable medium as recited in claim 13, wherein the resource is represented as an internet information service (iis) metabase node.
16. a computer-readable medium as recited in claim 13, wherein the request comprises a scope associated with the user, and a name of a method associated with the operation.
17. a computer-readable medium as recited in claim 13, wherein the resource is a web site hosted by an internet service provider (isp), and wherein the user is not a member of the administrators group.
18. a computer-readable medium as recited in claim 13, wherein the request further comprises an indication of whether the operation is to be executed via a dynamically built command line or via an executable object already associated with the operation.
19. a computer-readable medium as recited in claim 13, wherein operations associated with determining whether to authorize the operations are secure at least because the user does not have access to user role-based permission(s) to perform the operation.
wherein the instructions for determining further comprise instructions for utilizing the mapping to identify whether the user has permission to perform the operation.
determining whether to authorize the operation as a function of whether the user has been delegated a role-based scope of authority to perform the operation, the role-based scope of authority not requiring the user to be a member of an administrators group associated with resources of the server.
24. a server as recited in claim 23, wherein the request is generated by at least one resource of the resources.
25. a server as recited in claim 23, wherein the operation is associated with modification of content and/or functionality of the resource.
26. a server as recited in claim 23, wherein the resource is represented as an internet information service (iis) metabase node.
27. a server as recited in claim 23, wherein the request comprises a scope associated with the user, a name of a method associated with the operation.
28. a server as recited in claim 23, wherein the resource is a web site hosted by an internet service provider (isp), and wherein the user is not a member of the administrators group.
29. a server as recited in claim 23, wherein the request further comprises an indication of whether the operation is to be executed via a dynamically built command line or via an executable object already associated with the operation.
30. a server as recited in claim 23, wherein the secure delegation administration framework is secure at least because it does not allow the user access to a mapping of user role-based permission to perform the operation directed to the resource.
means for determining whether to authorize the operation as a function of whether the user has been delegated a role-based scope of authority to perform the operation, the role-based scope of authority not requiring the user to be a member of an administrators group associated with the server.
35. a server as recited in claim 34, wherein the operation is associated with modification of content and/or functionality of the resource.
36. a server as recited in claim 34, wherein the resource is an internet information service (iis) metabase node.
37. a server as recited in claim 34, wherein the resource is a web site hosted by an internet service provider (isp), and wherein the user is not a member of the administrators group.
means for executing the operation within a scope associated with the user.
mxpa04007143a mxpa04007143a (en) 2003-08-28 2004-07-23 delegated administration of a hosted resource.
gb2353875a (en) 1999-09-04 2001-03-07 hewlett packard co computer access control system.