Project Phases

1. Discovery/Submission
2. Problem Analysis
3. Solution Design
4. Development/Test
5. Deployment
6. Operation
7. Retirement

WebLogic JMS

Voir : http://middlewaremagic.com/weblogic/?p=6334

X Window Forwarding

ssh -X ... avec ~/.ssh/config:

Host *
        ForwardAgent yes
        ForwardX11 yes
        CheckHostIP no
        StrictHostKeyChecking no

SAML SubjectConfirmation

Voir:

• Web Service Security SAML Profile
• Fuse ESB Basic Scenarios

This element provides the means for a relying party to verify the correspondence of the subject with the party with whom the relying party is communicating. This is important for guarding against replay attacks, where an unauthorized user takes a SAML assertion from an earlier trapped message and reuses it for another message with a different SOAP body.


First definition from the standard:

• bearer: the relying party will allow any party that bears the assertion. No specific steps are taken to establish the relationship. Protection of the SOAP message, if required, must be performed using a transport level mechanism or another security token, such as Kerberos, for message level protection
• holder-of-key: the relying party will allow any party capable of demonstrating knowledge of specific key information to use the assertion
• sender-vouches: the relying party will use other criteria in determining which parties should be allowed to use the assertion. The SAML token contains insufficient data for the relying party to trust the incoming message. The relying party must perform an additional verification step to confirm that the SAML token is trustworthy. The attesting entity, presumed to be different from the subject, vouches for the verification of the subject. An attesting entity uses the sender-vouches confirmation method to assert that it is acting on behalf of the subject of SAML statements attributed with a sender-vouches SubjectConfirmation element.

Other definition from this blog article:

• holder-of-key: for this confirmation method, the outgoing soap envelope has been signed by the SOAP client. The STS (Secure Token Service, the SAML token/assertion generator) takes the public key of the SOAP client and places it in the SAML token it is creating, and signs the token with its own private key. Next, the SOAP client adds that SAML token to the SOAP header and constructs the SOAP body, signs it with its own key, and makes a SOAP client call. The web service provider validates that the SAML token came from an STS that it trusts (doable because the STS signed the token), and using the public key of the SOAP client within the SAML token, validates that the SOAP message as a whole came from that client.
  
  The holder-of-key method is best when the SOAP client request is not yet available, e.g., if the SOAP client requests the SAML token and then creates the rest of the SOAP envelope. By placing the SOAP client's public key in the SAML token and subsequently signing it, the STS can vouch for whatever that SOAP client may wish to subsequently sign
• sender-vouches: here, a user is authenticated with an intermediary using another mechanism such as username/password. After this is done, the intermediary requests a SAML token from an STS, a separate web service. The SAML token will contain the user's identity but, unlike the HOK method, no key information. The STS signs the assertion and sends it back to the intermediary, which in turn signs the assertion (again) and the rest of the SOAP request and finally sends the request to the web service provider. Here the intermediary is doing the vouching for the user by signing both the assertion and the SOAP body. To trust that the user has been authenticated, the web service provider must have a trusted relationship with both the intermediary and the STS. After validating the SAML assertion, the web service provider generates the response and sends it back to the intermediary, who forwards it on to the client.

Other definition from this blog article:

Subject confirmation methods are how a relying party (RP), in other words the end service, can make sure a particular security token issued by a Security Token Service (STS), is brought by the legitimate subject. If this is not done, a third party can take the token from the wire and send any request it wants including that token. RP will trust that illegitimate party. Following discuss these three methods.

The common aspect is, obviously, RP should always trust the STS.

• bearer: this is actually not a confirmation method. Subject confirmation is not needed! The RP simply trusts whoever brings the token.
• holder-of-key:

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

• sender-vouches:
1. Rather than authenticating with the STS, the client authenticates with an intermediary
2. The intermediary gets the security token from the STS
3. Then it signs the request and sends it to the RP
4. The RP trusts both the intermediary and the STS. So, it validates both of them.

Note:

If present, the <saml:SubjectConfirmation> element occurs within the subject element, and defines one or more methods (i.e., <saml:ConfirmationMethod> elements) by which the statement may be confirmed and will include a <ds:KeyInfo> element when any of the specified methods are based on demonstration of a confirmation key. The <saml:SubjectConfirmation> element also provides for the inclusion of additional information to be applied in the confirmation method processing via the optional <saml:SubjectConfirmationData> element

Putty with X Terminal and Much More

Moba X Term

SMTP Relayer

Mady MTA

Remove SOA Domain

1. make sure that all the servers in the domain have been shutdown properly.
2. Delete your domain directory under $MW_Home\user_projects\domains
3. Delete your domain directory under $MW_Home\user_projects\applications
4. Drop the existing schemas and recreate new one using RCU
5. Remove domain from $MW_Home\domain-registry.xml
6. Remove domain from  $MW_Home\wlserver10.3\common\nodemanager\nodemanager.domains

See also: http://www.oracle-base.com/articles/11g/weblogic-11g-create-extend-and-remove-domains.php

Oracle SOA Suite Installation on Windows 7 64 bits

setup.exe -jreLoc ...
   does not work, instead use:

install\win64\setup.exe
   and provide the path to 64 bits JDK when prompted

java -d64 -jar wls1036_generic.jar (installation du serveur WebLogic)