Clients that use the Java stubs can authenticate through basic authentication, or alternatively by using an HTTP client and the S2S servlet.
The Service to Service (S2S) authentication framework provides a means for a trusted partner application to establish user sessions with a trusting provider application on behalf of its users, without having to supply any credentials for the users individually.The partner application instead supplies a digest credential with each user session login request (or potentially, a basic credential over HTTPS) that is used to validate/authenticate the partner as being trusted to the particular provider service.
Oracle Content Services operates as the trusting provider service, with the partner service being potentially any application (registered/configured with Oracle Internet Directory) that is capable of establishing a client SOAP over HTTP Web Service connection with digest authentication headers. For this manager to function, the server must be configured for S2S authentication, and the domain property IFS.DOMAIN.CREDENTIALMANAGER. ServiceToServiceAuthenticationEnabled must be
set to true. Use the Oracle Collaboration Suite Control to set domain properties.
S2S Login manager provides facilities to:
Oracle Content Services operates as the trusting provider service, with the partner service being potentially any application (registered/configured with Oracle Internet Directory) that is capable of establishing a client SOAP over HTTP Web Service connection with digest authentication headers. For this manager to function, the server must be configured for S2S authentication, and the domain property IFS.DOMAIN.CREDENTIALMANAGER. ServiceToServiceAuthenticationEnabled must be
set to true. Use the Oracle Collaboration Suite Control to set domain properties.
S2S Login manager provides facilities to:
- Authenticate a user with given user name. The S2S header ORA_S2S_PROXY_USER must also be set to the value of the supplied user’s Oracle Internet Directory nickname attribute.
- As an example, consider a custom application that renders information pertaining to the user’s most recently accessed documents in Oracle Content Services. The runtime flow would be similar to the following:
- User authenticates to Oracle Portal
- A default portal user home page is requested to be displayed that contains the "most recent documents"
- The application checks to see if an existing Oracle Content Services session cookie exists for the user in the user’s HttpSession (or equivalent) object store. If no existing session exists, proceed with service to service authentication. Otherwise,obtain a FileManager (step 7) and make the appropriate call.
- The application obtains the portal service's credentials from a credential store (such as Oracle Internet Directory)
- The application initiates a Web Service request to the Oracle Content Services. ServiceToServiceLoginManager with digest authentication HTTP headers present that identify the partner service (Oracle Portal), and HTTP header ORA_S2S_PROXY_USER set to a non-null value (for example, "matt"). The ServiceToServiceLoginManager login method is called, supplying the user name of the portal authenticated user ("barani"[@non-default realm])
- A session cookie is returned that identifies the newly created Oracle Content Services user session. This, in turn, is stored in an appropriate location, such as the user’s HttpSession object.
- Using the session cookie, obtain a FileManager, and then call the getMostRecentDocuments method.
- Process the returned item array and render application results.
No comments:
Post a Comment