1. Call to get Ticket Granting Ticket

   Request

   POST /cas/v1/tickets HTTP/1.1
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 35
   
   username=fwadmin&password=xceladmin
   

   Response

   HTTP/1.1 201 Created
   Location: http://localhost:8080/cas/v1/tickets/TGT-1-ej2biTUFoCNBwA5X4lJn4PjYLRcLtLYg2QhLHclInfQqUk3au0-cas
   Content-Length: 441
   ...
   

2. Call to get a Service ticket

   Request

   POST /cas/v1/tickets/TGT-1-ej2biTUFoCNBwA5X4lJn4PjYLRcLtLYg2QhLHclInfQqUk3au0-cas  HTTP/1.1
   Content-Type: application/x-www-form-urlencoded 
   Content-Length: 57
   
   service=http%3A%2F%2Flocalhost%3A8080%2Fcs%2FREST%2Fsites 
   

   Response

   HTTP/1.1 200 OK
   Content-Type: text/plain
   Content-Length: 29
   
   ST-1-7xsHEMYR9ZmKdyNuBz6W-cas
   

To use the generated ticket/multiticket, supply the ticket/multiticket URL query parameter. For example:

http://localhost:8080/cs/REST/sites?ticket=ST-1-7xsHEMYR9ZmKdyNuBz6W-cas
http://localhost:8080/cs/REST/sites?multiticket=ST-2-Bhen7VnZBERxXcepJZaV-cas

Figure 51-1 Tickets and Multitickets

Description of "Figure 51-1 Tickets and Multitickets"

1. The application performs a call to get the ticket/multiticket.

   • Input: service, user name, password

   • Output: ticket /multiticket

2. The application performs call to Remote Satellite Server to get the resource.

   • Input: ticket, resource input data

   • Output: resource output data

3. Remote Satellite Server performs a call to validate the resulting assertion. The assertion contains user information. Satellite Server also maintains a time-based cache of multitickets, so that subsequent calls do not incur the cost of validation.

   • Input: ticket/multiticket

   • Output: assertion

4. This step is optional. The proxyTickets parameter, when set to true in the SSOConfig.xml file on the Satellite Server side, also proxies the ticket.

   • Input: ticket

   • Output: proxied ticket

5. Remote Satellite Server performs a call to WebCenter Sites.

   • Input: assertion (in serialized form), resource input data

   • Output: resource output data

6. This step is optional. If security is enabled on the WebCenter Sites side, it performs a call to validate the ticket.

   • Input: ticket/multiticket

   • Output: assertion

The single sign-on module relies on the Spring configuration. The only required bean is ssoprovider, which references the ssoconfig bean.

This section includes the following topics:

• Beans and Properties

• Query Parameters Processed by SSO Filter

The WEM security model is based on objects, groups, and actions. Security must be configured per object type in the Admin interface. Objects of a given type are accessible to a user only if the user belongs to at least one group with privileges to perform specified actions on the objects of the given type.

Figure 51-2 Add New Security Configuration

Description of "Figure 51-2 Add New Security Configuration"

• Object is a generic term that refers to any entity in the WEM Framework such as a site, a user, or an asset. Protected objects are of the following types:

  • Asset Type

  • Asset

  • Index

  • Site

  • Role

  • User

  • User Locale

  • ACL

  • Application

• Security groups are used to gather users for the purpose of managing their permissions (to operate on objects) simultaneously.

• An action is a security privilege: LIST,READ, UPDATE, CREATE, DELETE. LIST provides GET permission on services that list objects (such as /types), whereas READ provides GET permission on services that retrieve individual objects in full detail (such as /types/{assettype}).

  Privileges are assigned to groups to operate on allowed objects. Some objects, such as ACLs, are read-only (they can be created directly in WebCenter Sites, but not over REST).

A security configuration is an array, such as shown above, which specifies:

• The protected object type and object(s)

• Groups that are able to access the objects

• Actions that groups (and their members) can perform on the objects

For more information about possible security configurations and the Web Experience Management Framework, see the Administering Oracle WebCenter Sites.

Object types and objects in WebCenter Sites map to REST resources in the WEM Framework. For example, the Asset Type object maps to:

• <BaseURI>/types/ resource (which lists all asset types in the system)

• <BaseURI>/types/<assettype> resource (which displays information about the selected asset type), and so on

Actions in WebCenter Sites map to REST methods in the WEM Framework. For example, granting the READ privilege to group Editor to operate on asset type Content_C gives users in the Editor group permission to use GET and HEAD methods on the REST resource /types/Content_C.

• The LIST action allows group members to use GET methods on REST resources.

• The READ action allows group members to use GET and HEAD methods on REST resources.

• The UPDATE action allows group members to use POST methods on REST resources.

• The CREATE action allows group members to use PUT methods on REST resources.

• The DELETE action allows group members to use DELETE methods on REST resources.

For comprehensive information, see the REST API Resource Reference for Oracle WebCenter Sites.

When configuring a security privilege, specify that the privilege applies to all objects of a certain type or a single object of a certain type. For example, granting the privilege to UPDATE (POST) any site allows users in the group to modify the details of all sites in the WEM Framework.

The Asset object type requires you to specify the site to which the security setting applies, as assets are always accessed from a particular site. The AssetType object can be extended by specifying a subtype, which is used to make the security configuration more granular. For example, setting the DELETE privilege on asset type Content_C allows a DELETE request to be performed on the REST resource /types/Content_C (that is, to delete the Content_C asset type from the system).

Because privileges can be granted only to groups, a user's total privileges are not obvious until they are computed across all of the user's groups. The WEM Framework provides a privilege resolution algorithm. Its basic steps are listed below:

1. REST finds the groups in which the user has membership.

2. REST determines which groups can perform which REST operations on which REST resources. If site or subtype is specified, each is taken into account.

3. REST compares the results of steps 1 and 2. Access is granted if at least one of the groups from step 1 is in the list of groups from step 2. Otherwise, access is denied.