In Bearer the sender of the message isn't necessarily the party that actually created the SAML Assertion; if they were then you could just use Sender Vouches and be done. In Bearer you're saying that the communication channel authenticates the caller; this also means that the party sending the message could get a SAML assertion from somewhere else and then just includes it in the SOAP message. There are a bunch of dangers in this sort of architecture, but you can mitigate most of them through appropriate architectural choices. What those dangers are and how you mitigate them is a subject for a separate post. There's a third confirmation method called Holder of Key which is, again, a great subject for another post.
First here's the table (shamelessly copied) from Gerard's post:
|Trust store location||wlserver_10.3/ server/lib/DemoTrust.jks|
|Trust store password||DemoTrustKeyStorePassPhrase|
|Key store location||wlserver_10.3/ server/lib/DemoIdentity.jks|
|Key store password||DemoIdentityKeyStorePassPhrase|
|Private key password||DemoIdentityPassPhrase|
As you can see there are two JKS files - DemoTrust.jks and DemoIdentity.jks. Take a look at the contents of them by using keytool:
keytool -list -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase keytool -list -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase
You'll find that DemoIdentity.jks contains a Private Key and DemoTrust.jks contains the associated Certificate (and a few others).
So for my little SOAP tester in my test environment I can use the DemoIdentity.jks file to sign the SAML Assertion and as long as OSB is configured to use DemoTrust.jks it should accept my SAML Assertion.
In the real world you definitely won't be using the DemoTrust keystore. Instead you'll create another Key Store to be used on the OSB server and you'll probably put the Certificate of the SAML assertion generator in there (if it's a self-signed cert) or the Cert chain needed to verify the signature.
Hope this helps!