Create an Application ID
-
Open SharePoint Central Administration.
-
Click Manage Service Applications and Secure Store
Service.
-
Click the New button on the ribbon, as shown in the
following graphic. Note that if this is the first time you’ve
done this, you might be required to generate a new key.
-
Now as shown in the following graphic, provide a target
application ID name, a display name, and a contact email
address. Leave the other options set to their defaults.
-
Click Next. Change the user name and password field names
to something more descriptive (such as SQL
Azure User Name and SQL Azure
Password). Make sure that you select User Name and
Password as the field types. Keep the password masked.
-
Click Next. Now provide a valid Active Directory alias as
the administrator of the target application definition. You can
designate multiple administrators, separating them with
semicolons.
You now have an application ID that you can use to connect
to the SQL Azure external system. You would use this Application
ID when creating your ECT. For example, you created an ECT by
using SharePoint Designer. In the following graphic, you can see
that you select Connect With Impersonated Custom Identity and
then add the Secure Store Application ID to complete the
handshake with the external system.
SharePoint Designer prompts you to enter your credentials when connecting to SQL Azure, and
you’ll again be prompted for credentials when you load the
external list for the first time. Credentials are then saved. If
the credentials change, you will be prompted to enter your
credentials again.
The second level of permissions is the ECT; you can assess permissions for
a specific user against the external system for Edit, Execute,
Selectable In Clients, and Set Permissions. (This second level of
permissions applies equally to either a SQL Azure external data
source or a WCF endpoint that you model by using the Business Data Connectivity Model template in Microsoft
Visual Studio.) Each of these permissions provides different levels
of access to BCS resources. For example, Edit enables you to create
new external systems and edit the model file. Execute enables you to
execute the method within the ECT. Selectable In Clients enables you
to create external lists by using the ECT. And Set Permissions
enables you to set any permissions in the metadata store. For more
information on these permissions, see the following TechNet article:
http://technet.microsoft.com/en-us/library/ee661743.aspx.
Assess Permissions on the ECT
-
Open SharePoint Central Administration.
-
Click Manage Service Applications, and then click Business
Data Connectivity Service.
-
Select an ECT in the list, and then click Set Object
Permissions.
-
Type the Active Directory alias for a user and click Add.
After the name resolves, select the permissions you want for
that user, as shown in the following graphic. Note that in this
screen shot, you’ve selected the highest level of privileges,
which should be reserved for administrators (or power users). In
many cases, you only need to give users Execute permissions so
they can execute all of the methods within the ECT.
-
Click OK to finish.
Assessing the user permissions by using the application ID is a very
simple process, and it provides you with a
per-user filter on an otherwise open outbound
connection. For example, suppose you create a WCF service ECT and create
web methods to support create, read, update, and delete (CRUD)
operations. Although the calling of your service supports CRUD, and
the ensuing ECT you create against that WCF service would support
CRUD, you can limit specific users to read-only access (or, of
course, give them CRUD access). In this sense, a claims-aware WCF
service might not be required because you can secure an individual
method on the ECT.
The most important point in this first section is that you
have granular control over who has access to SQL Azure data using
BCS and external lists. You should see Execute as the
fundamental, baseline privilege you assess users and then proceed
more deeply based on your needs.
Another type of data storage for which you built an
application was Windows Azure BLOB storage, which has a flexible
security model. In the next section, you’ll see how you can use
shared access permissions to control access to resources in BLOB
storage.
