SAML webservices

This post provides references and links for Oracle WebLogic integration with SAML protocol for authentication. The primary reference is the WebLogic security architecture. One can integrate Oracle WebLogic server with SAML based federation. Here is official Oracle documentation that provides details and architecture for Single Sign on (SSO) with WebLogic server. The Use Case is Single Sign on as depicted in the diagram below.

SSO Use Case

WebLogic Security Framework provides the necessary configuration and infrastructure to support SAML based Single Sign on. 
Refer this below diagram that provides the various actors and steps in SAML based authentication and single sign on. This classic diagram is from oasis standards.

SP initiated SSO with Redirect and HTTP Post binding

Example of SP initiated SSO using PingFederate as an Identity Provider
Above diagram shows a practical example (taken from alfresco.com website) with Service Provider initiated SSO with HTTP Post Bindings, with PingFederate as the Identity Provider. Here the flow is same as above generic saml flow from oasis website. The only difference between the above two diagrams is that in oasis provided flow shows step 2 and 3 are shown as two different steps (that's why it has has 8 steps as compared to below diagram which has 7 steps).
Compare this with PingFederate documentation that describes this SSO flow in below steps (for SP initiated SSO)

Steps for the SP initiated Post Redirect bindings

1) A user requests access to a protected SP resource. The user is not logged on to the site. The request is redirected to the federation server to handle authentication.

2) The SP returns an HTTP redirect (code 302 or 303) containing a SAML request for authentication through the user's browser to the IdP's SSO service.

3) If the user is not already logged on to the IdP site or if re-authentication is required, the IdP asks for credentials (e.g., ID and password) and the user logs on.

4) Additional information about the user may be retrieved from the user data store for inclusion in the SAML response. (These attributes are predetermined as part of the federation agreement between the IdP and the SP—see About attributes.)

5) The IdP's SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP.

NOTE: SAML specifications require that POST responses be digitally signed.

6) (Not shown) If the signature and the assertion (or the JSON Web Token) are valid, the SP establishes a session for the user and redirects the browser to the target resource.

Here is a good tutorial and here, for step-by-step guide to developing SAML based webservices. dailyraaga.wordpress.com

Note on Holder of Key, Bearer

http://docs.oracle.com/cd/E12839_01/web.1111/e13710/archtect.htm

• Sender-Vouches – The asserting party (different from the subject) vouches for the verification of the subject. The receiver must have a trust relationship with the asserting party.
• Holder-of-Key – The purpose of SAML token with “holder-of-key” subject confirmation is to allow the subject to use an X.509 certificate that may not be trusted by the receiver to protect the integrity of the request messages.Conceptually, the asserting party inserts an X.509 public certificate (or other key info) into a SAML assertion. (More correctly, the asserting party binds a key to a subject.) In order to protect this embedded certificate, the SAML assertion itself must be signed by the asserting entity. For WebLogic Server, the Web Service client signs the SAML assertion with its private key. That is, the signature on the assertion is the signature of the SAML authority, and is not based on the certificate contained in, or identified by, the assertion.
• Bearer – The subject of the assertion is the bearer of the assertion, subject to optional constraints on confirmation using attributes that may be included in the element of the assertion.

As per http://dulanja.blogspot.in/2013/01/saml-subject-confirmation-methods.html

Bearer

This is actually not a confirmation method – means subject confirmation is not needed! The RP simply trusts whoever brings the token! (RP has to trust the STS or IDP in a Federation)

Holder of Key (HoK)
1. STS includes the public key of the client, inside the security token and signs it.
2. Then before sending, client itself signs the request.
3. When the RP receives it, it first validates STS signature and then validates client’s signature with the public key embedded inside the token.

Sender Vouches
1. Rather than authenticating with the STS, here, Client authenticates with an intermediate service.
2. The intermediary gets the security token from the STS.
3. Then it signs the request and sends to the RP.
4. RP trusts both the intermediary and the STS. So, it validates both of them.

Note on Keystore for WebLogic server
Note: The WebLogic Keystore provider is deprecated in this release of WebLogic Server but is still supported. The development of custom Keystore providers is not supported. Use Java KeyStores (JKS) instead. Oracle recommends using the WebLogic Keystore provider only when it is needed to support backward compatibility with a WebLogic Server 7.0 configuration. For information on how to use Java KeyStores, see "Configuring Keystores for Production"in Oracle Fusion Middleware Securing Oracle WebLogic Server

.
.
.