To enable gadget whitelisting set the property gadgets.admin.enableGadgetWhitelist in your containers configuration file (container.js) to true. You also need to provide an implementation for the GadgetAdminStore interface in Shindig. Shindig calls the isWhitelisted method in this interface to determine whether a gadget is on the whitelist or not. Your implementation of this method can point to whatever whitelist store you may have.
Enabling and Disabling Features For Gadgets
Shindig 3.0 provides administrators a way to say which features are disable or enabled for a specific gadget in a specific container. To enable this functionality set gadgets.admin.enableFeatureAdministration to true in your container's configuration file (container.js). You also need to provie an implementaiton for the GadgetAdminStore interface. This will interface with whatever you are storing your feature admin information in. In Shindig the reference implementation uses a static JSON file. However a quick overview of this file will give you an idea of what you can do.
Securing RPC Calls Made To The Container
Any gadget has the ability to make an RPC call to any RPC endpoint. This can be dangerous if the RPC endpoint returns data which may be sensitive information. In order to secure the RPC endpoints a gadget is allowed to call we tie into information specified in the feature XML file. Feature developers should specify any RPC endpoints they call in their feature XML. They can do this by using the <uses> tag.
The uses tag basically allows the feature developer to declare the RPC endpoints their code uses. This information will get gathered for every feature a gadget uses and sent down to the container when the gadgets metadata is requested. The container will then use this information to check every RPC call made from the gadget to the container to see if the RPC service ID the gadget is calling is allowed. To enable this functionality set enableRpcArbitration to true in your containers configuration.
There may be scenarios where you may want to provide RPC services but not declare them in features. In these scenarios you should specify the which gadgets are allowed to use these RPC service ids. There is a method in the interface GadgetAdminStore called getAdditionalRpcServiceIds, which returns a set of additional RPC service IDs you want to allow for that gadget. In the default implementation in Shindig, you can specify this list on a per gadget basis in gadget-admin.json by setting an array of service ids in the additionalServiceIds property. This property should be part of the rpc object for each gadget.