OWSM: SAML Verify WSS 1.0 Token

Hi,
I have created a policy for a service registered with the gateway with 'SAML - Verify WSS 1.0 Token' as one of the steps in the Request pipeline. I am using JKS as the store type. When a client tries to invoke the service, it gets the following error from the gateway:
javax.xml.rpc.soap.SOAPFaultException: Did not understand "MustUnderstand" header(s)
On the other hand gateway.log shows the following message:
saml.SAMLProcessor - SAML assertion confirmation method: urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
The client is a J2SE client created using JDeveloper.
Am I missing something important here?
Any help would appreciated.
Thanks

Normally, the mustUnderstand error is given out by the OC4J web service when the service receives a SOAP request with a security header with mustUnderstand attribute set to 1.
What is the SOAP message being received by the web service itself?
Vikas Jain
http://ws-security.blogspot.com

Similar Messages

OWSM SAML Verify step problem: Missing Security Header in SOAP message

I'm having a problem with SAML steps. From gateway log:
2008-09-17 13:21:32,987 INFO [HTTPThreadGroup-58] saml.InsertSAMLSVStep - User attributes map set to generate the attribute assertions: null
2008-09-17 13:21:33,034 INFO [HTTPThreadGroup-60] saml.SAMLProcessor - Assertion Major Version :1 , Minor Version :1
2008-09-17 13:21:33,034 WARNING [HTTPThreadGroup-60] saml.SAMLProcessor - SAML Assertion verification error: An invalid token was provided
2008-09-17 13:21:33,034 WARNING [HTTPThreadGroup-60] saml.VerifySAMLStep - SAML Token verification failed:
2008-09-17 13:21:33,096 SEVERE [HTTPThreadGroup-58] wssecurity.OSDTWSSecurity - Missing Security Header in SOAP message
2008-09-17 13:21:33,096 WARNING [HTTPThreadGroup-58] wssecurity.SecurityBaseStep - Failure while applying XML Security
FAULT CODE: InvalidSecurity FAULT MESSAGE: Missing WS Security header in the SOAP message
at com.cfluent.policysteps.security.wssecurity.OSDTWSSecurity.decryptVerify(OSDTWSSecurity.java:369)
at com.cfluent.policysteps.security.wssecurity.DecryptStep.performXmlSecurity(DecryptStep.java:131)
at com.cfluent.policysteps.security.wssecurity.SecurityBaseStep.execute(SecurityBaseStep.java:238)
at com.cfluent.pipelineengine.container.DefaultPipeline.executeStep(DefaultPipeline.java:124)
but the wsse:Security header with SAML assertion IS confirmed in the incoming message log. Anybody seen this issue?

Below is the log of the incoming message just prior to the failing SAML Verify step:
<?xml version="1.0" encoding="UTF-8" ?>
- <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0="http://exception.common.periop.gehc.com" xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns2="http://www.patient.patientmanager.periop.gehc.com/service/" xmlns:ns3="http://entity.common.periop.gehc.com" xmlns:ns4="http://entity.patient.patientmanager.periop.gehc.com" xmlns:ns5="http://entity.allergy.patientmanager.periop.gehc.com" xmlns:ns6="http://pdo.domain.customizer.periop.gehc.com" xmlns:ns7="http://entity.cases.scheduler.periop.gehc.com" xmlns:ns8="http://entity.insurance.patientmanager.periop.gehc.com">
- <env:Header>
- <ns1:Security>
- <saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="158RBY2QvCFPiTqdXYWh9A22" IssueInstant="2008-09-17T19:58:43Z" Issuer="GE" xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions NotBefore="2008-09-17T19:58:13Z" NotOnOrAfter="2008-09-17T19:59:43Z" />
- <saml:AuthenticationStatement AuthenticationInstant="2008-09-17T19:58:43Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
- <saml:Subject>
<saml:NameIdentifier NameQualifier="www.ge.com" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">gowri</saml:NameIdentifier>
- <saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</ns1:Security>
</env:Header>
- <env:Body>
- <ns2:getPatient>
<ns2:patientId>137115</ns2:patientId>
</ns2:getPatient>
</env:Body>
</env:Envelope>

OWSM SAML verification and Must Understand error

Has anyone verified SAML tokens generated by JDev proxies by OWSM?
I tried to use the simplest scenario (similar to what I had tested when verifying SAML with Application Server) with OWSM. I don't use signature and just sender vouches at the proxy side. On the other side, OWSM, I have a gateway which has one step in the request pipeline which verifies SAML.
I get this response message:
<?xml version = '1.0' encoding = 'UTF-8'?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0="http://project1/types/">
<env:Body>
<env:Fault>
<faultcode>env:MustUnderstand</faultcode>
<faultstring>*SOAP must understand error: {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security*</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
Regards
Farbod
P.S. this is my request message:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0="http://project1/">
<env:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" env:mustUnderstand="1">
<wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" wsu:Id="B1tdL86gkmAN00oYpfTmOw22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:KeyIdentifier xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">lrLlLdbWLda851vHdngAEA22</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
<saml:Assertion MajorVersion="1" MinorVersion="1" xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="lrLlLdbWLda851vHdngAEA22" IssueInstant="2008-10-11T08:46:36Z" Issuer="www.oracle.com">
<saml:Conditions NotBefore="2008-10-11T08:46:36Z" NotOnOrAfter="2008-10-12T08:46:36Z"/>
<saml:AuthenticationStatement AuthenticationInstant="2008-10-11T08:46:36Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
<saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">www.oracle.com</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</wsse:Security>
</env:Header>
<env:Body>
<ns0:jamshidElement/>
</env:Body>
</env:Envelope>

Without more specific about the SOAP Fault you are getting, the version and the type of client you built, it will be hard to give you specifics.
You may want to verify that the policy used to configure the client proxy does match with the server-side.
Usually, this error is generated during deserialization of a SOAP envelope when some SOAP header contains the mustUnderstand attribute with the value set to true and are not ready (configured) to process this specific header.
It could be just a version mismatch; I process header in the foo namespace, but this one was in the bar namespace.
Hope it helps,
-Eric

Owsm saml policies

Hello,
In the Oracle documentation, the following is said about some saml policies:
oracle/wss10_saml_token_service_policy
oracle/wss10_saml_token_client_policy
This policy is not secure and is provided for demonstration purposes only. Although the SAML issuer name is present, the SAML token is not endorsed. Therefore, it is possible to spoof the message.
I really have no idea what is meant by this. Can anyone explain?
Thanks and regards, Jeroen

Hi, I am using Weblogic Oracle 12c and standalone server no clusters. I have a webservice configured which is working from the Weblogic, using DemoTrust.jks I just downloaded the SOAP-UI and having issues with this, I set up the aut Tab to use Global HTTP Settings for the authorization type and added a keystore which is pointing to the DemoTrust.jks.
When I run a test, I receive this error
Tue Jul 31 09:40:38 PDT 2012:DEBUG:<< "<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header/><env:Body><env:Fault xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><faultcode>wsse:InvalidSecurity</faultcode><faultstring>Error on verifying message against security policy Error code:1000</faultstring></env:Fault></env:Body></env:Envelope>"
You wouldn't know what this is about, from what I am reading it seems I need to pass a policy to the server from the client but unsure what to configure.
If you have any insight I would appreciate it.

OWSM: SAML message protection policy question

My web services are protected with SAML message protection policy. according to document:
http://download.oracle.com/docs/cd/E15523_01/web.1111/b32511/setup_config.htm#BABJAIHD
On the web service side, "+Needs the intermediary and root certificate corresponding to the client's public key in the keystore.These certificates will be used to verify the signature by generating a trusted certificate chain+."
Also says "+Generally, the recipient does not need to have the sender's public key in its keystore to validate the certificate. It is sufficient to have the root certificate in the keystore to verify the certificate chain+."
Since weblogic default trust store have more than 60 well known CA's trust intermediary and root certificate by default, does this mean that if web service client own a key signed by one of these well know CA, he will be able to access my web service through SAML policy?
What if I would like to limit my web service only to specified client instead of public access, should I remove those well known intermediary and root certificate from weblogic trust store?
Thanks

Hi RaJdeep,
Thank you for your inputs.But I couldnot get what I have to do here.
Could you please pass on your contact details so that I can contact you.
Thank you in advance.
Regards
Narendra

OWSM: Setting up SAML token verification with Novell Access manager

Hello,
We are trying to set-up communication between an OWSM gateway and a Novell Accces Manager to do the following:
All requests to our services should be secured using Web Services Security SAML Token Profile 1.0. OWSM will validate this token using the SAML – Verify WSS 1.0 Token step. The assertion will be issued by a Novell Access Manager. Are we right that OWSM needs to communicate with the Novell Access Manager for this? In that case Novell requires us to deliver metadata to establish a trust relation between the Identity Provider (Novell) and the Service Provider (OWSM). This metadata should look something like this:
odysseus:/var/opt/novell/tomcat4/webapps/nidp # cat application.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN' 'http://java.sun.com/j2ee/dtds/application_1_2.dtd'>
<application>
<display-name>NIDPJ2EEApp</display-name>
<description>Novell Identity Provider</description>
<module>
<web>
<web-uri>nidp.war</web-uri>
<context-root>nidp</context-root>
</web>
</module>
</application>
However I cannot find anything on this in the OWSM documentation.

To answer my own question. We found 4 application.xml files which seem to contain the metadata in the folders ccore, coreman, gateway and policymanager of $AS_HOME/owsm/config/.

Using OWSM for SAML verification and LDAP authorization

I can verify SAML tokens by using EM security (verifying SAML tokens) but when I use OWSM I get this error at the proxy (by adding the step : SAML - Verify WSS 1.0 Token to the policy of a server agent)
Exception in thread "main" java.lang.NoSuchMethodError: oracle.security.wss.saml.SAMLAssertionIssuer.<init>(Ljavax/xml/rpc/handler/soap/SOAPMessageContext;Lorg/w3c/dom/Document;Loracle/security/wss/config/SamlTokenConfigType;Z)V
Also I need to LDAP authorize the subject of SAML after verification of SAML token. Is it just enough to put the LDAP authorize step after SAML verification?
Won't I need any EXTRACT CREDENTIAL step?
Regards
Farbod

When we were asked to combine OBIEE 10g with Active Directory, we chose external Table Authorization to get information on the groups, a user is part of.
In general, one could follow these articles to achieve AD Authentication:
[http://www.oraclebidwh.com/2008/10/obiee-ldap-authentication-using-microsoft-ad/|http://www.oraclebidwh.com/2008/10/obiee-ldap-authentication-using-microsoft-ad/]
[http://www.oraclebidwh.com/2008/11/obiee-ldap-authentication-using-microsoft-ad-2/|http://www.oraclebidwh.com/2008/11/obiee-ldap-authentication-using-microsoft-ad-2/]
To sum it up: Read User-information from AD. Knowing a user's login-name then, one could query an external table, which consists of user and group information. Everything is setup within initializationBlocks, which could be created in the administration tool.
Problem: As you already said, the problem is, that this external user--group table has to be filled and updated "manually". That is, someone has to input new users or at least assign them to the existing groups.
In our case, there's an admin who knows what sql is and how to work with it.
Another solution could be, to prepare a xml-file, containing user and group information and add it to your repository. The tables could then be queried, too. Although, xml files can become quite unhandy, if a lot of information is held within it, they can be edited via external tools or at least with a standard text editor.

SAML Sender-Vouches errors when using with OWSM

Hi,
We have configured OWSM Policy 'SAML - Verify WSS 1.0 Token' with Allow signed assertions only. We have created jks Trust store location and configured policy to refer to the file with appropriate password.
We have created proxy security to Sender-Voches signed and to sign outbound message.
We are getting following error when we try to run the proxy.
javax.xml.rpc.soap.SOAPFaultException: SAML token verification failed
at oracle.j2ee.ws.client.StreamingSender._raiseFault(StreamingSender.java:555)
at oracle.j2ee.ws.client.StreamingSender._sendImpl(StreamingSender.java:396)
at oracle.j2ee.ws.client.StreamingSender._send(StreamingSender.java:112)
at vigni4.oracle.srtutorial.datamodel.proxy.runtime.TimeServiceSoap_Stub.getTime(TimeServiceSoap_Stub.java:79)
at vigni4.oracle.srtutorial.datamodel.proxy.TimeServiceSoapClient.getTime(TimeServiceSoapClient.java:41)
at vigni4.oracle.srtutorial.datamodel.proxy.TimeServiceSoapClient.main(TimeServiceSoapClient.java:29)
Process exited with exit code 0.
and Error in gateway.log is
2007-09-01 18:58:56,561 WARNING [RMICallHandler-58] saml.VerifySAMLStep - SAML Token verification failed:
Can any provide information on how to resolve the issue?

We have also noticed that correct message is reaching OWSM.
Attaching the same.
<?xml version="1.0" encoding="UTF-8" ?>
- <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0="urn:Test:GetTime">
- <env:Header>
- <wsse:Security env:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<wsse:BinarySecurityToken ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" wsu:Id="_FNfXFOVi1OcPKSyRUAHDyw22" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIICQjCCAasCBEbZZN4wDQYJKoZIhvcNAQEFBQAwaDELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEDAOBgNVBAcTB3NhbUhvbWUxDzANBgNVBAoTBnNhbU9yZzEQMA4GA1UECxMHc2FtRGVwdDESMBAGA1UEAxMJU2FtIE1vb3JlMB4XDTA3MDkwMTEzMTA1NFoXDTA3MTEzMDEzMTA1NFowaDELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEDAOBgNVBAcTB3NhbUhvbWUxDzANBgNVBAoTBnNhbU9yZzEQMA4GA1UECxMHc2FtRGVwdDESMBAGA1UEAxMJU2FtIE1vb3JlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOrVJbJ/sPvZsgZEDUSIolP1UDT8hfyajfIaPqYHBLBK+FlywrhhrxESyzAsG/k7FSIRZvFg5vAk/W3LB+nPBtrbI2bBMEsQbznuSjzEVkQJVxZMlDjR4yNMHPLbniL64BKuTFnLEhWrnZTmpiThjwoWMPL9eK7/x7su9iDCP5NwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBADWjdaRz0FBNHxXPiV9Ad0Kkm2Eag5LQXQoXUuC/VTXk56uQktVLtorp5fYAUsRD2o7ZuPGPJ6Q+5Owe8wXbxrCOX1diI5fxpH5TsS0k8Y/7/Hx3gq67JuPy8x8ApgNd+NagAKHKC0rgEP9ng1FGyhzuHICapPxmjrt2VI3SW2cJ</wsse:BinarySecurityToken>
- <dsig:Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
- <dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
- <dsig:Reference URI="#mvDwzM5hZWAdG6n5tKLufA22">
- <dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<dsig:DigestValue>zBFquf+Y0ngNapyK4Xq0Jws1FPM=</dsig:DigestValue>
</dsig:Reference>
- <dsig:Reference URI="#nwWnNm69TPcdyp0yT8fa7g22">
- <dsig:Transforms>
- <dsig:Transform Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform">
- <wsse:TransformationParameters xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</wsse:TransformationParameters>
</dsig:Transform>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<dsig:DigestValue>rgHU/BWcaOiwuP/Q72oybFcEQO8=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>R+RGFjzRYpGVPGINbzsFbXSQ7Slc04/mzQ+BX57oD7NhMKxCcO1C9cV2cJzWAeN5WuDlfsh3RZR/5sTsyEi3yO69ECcLUNDlbjey57GBr5W9PRRIWPs2fZVk2EH4+KOnXVghcAsrXPgm1Ai9UZQUXh0aPiOkQMDplnnhENTkKUo=</dsig:SignatureValue>
- <dsig:KeyInfo>
- <wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:Reference URI="#_FNfXFOVi1OcPKSyRUAHDyw22" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" />
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
- <wsse:SecurityTokenReference wsu:Id="nwWnNm69TPcdyp0yT8fa7g22" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">YFfqXnq2xlt426HB9uDInw22</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
- <saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="YFfqXnq2xlt426HB9uDInw22" IssueInstant="2007-09-01T13:40:06Z" Issuer="https://phaos.com/idp" xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions NotBefore="2007-09-01T13:40:06Z" NotOnOrAfter="2007-09-02T13:40:06Z" />
- <saml:AuthenticationStatement AuthenticationInstant="2007-09-01T13:40:06Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
- <saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">oc4jadmin</saml:NameIdentifier>
- <saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</wsse:Security>
</env:Header>
- <env:Body wsu:Id="mvDwzM5hZWAdG6n5tKLufA22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
- <ns0:getTime env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<format xsi:type="xsd:string" />
</ns0:getTime>
</env:Body>
</env:Envelope>

Validate SAML token with WSM

I'v posted this thread in the [SOA Suite forum|http://forums.oracle.com/forums/thread.jspa?threadID=912083&tstart=0] in the first place, but maybe this forum is a better places, for this question.
We're experiencing a lot of inconveniences using the "SAML - Verify WSS 1.0 Token" validation step in WSM. We've configured the SAML verifier to "allow signed assertions only" in order to achieve our security goals. Before a client is allowed access to a protected web service, the client must request an identity provider to get a signed saml assertion and attach this security token to the web service security header. In order to access the protected web services we'll like to use WSM to verify that the saml assertion:
1. Is issued by a specific identity provider (no problem)
2. That the conditions in the assertion is valid (no problem)
3. That the assertion i signed by a trusted certificate (problem)
4. That the signature of the assertion is valid in proportion to the signed context of the assertion (problem)
The inconveniences starts when we expect that the "SAML - Verify WSS 1.0 Token" validation step, validates the signatures of the assertion, before using it. But it seems, that this isn't the purpose of the verifier. When the saml token verifier is configured with "allow signed assertions only", then the client receives a "SAML token verification failed". This seems reasonably, but if we just add an empty ds:Signature element inside the wsse:Security element, then the client is granted access:
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<ds:Signature Id="Signature-11551252" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"></ds:Signature>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="nakbhwl3Qz8mPC00cL1bUg22" Issuer="https://credentials.com/idp" IssueInstant="2009-06-09T11:05:40Z">
</saml:Assertion>
</wsse:Security>
I find this behavior very strange. Also, if i do some manual changes in the saml assertion issued and signed by the identity provider, this is allowed too, even though the signature is invalidated. Event if I remove the ds:Signature from the assertion, but keeps the empty ds:Signature below the wsse:Security element, the client is granted access.
In the documentation of the "SAML - Verify WSS 1.0 Token", i found this quotation:
"Verifies the SAML token according to the Web Services Security SAML Token Profile 1.0 (WSS STP 1.0) standard."
But I don't find this statement true. Our assertions is issued with confirmation method "sender-voches":
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
I interpret the spec as, a receiver MUST NOT accept assertions containing a "sender-vouches" confirmation method unless the assertions and soap message content being vouches for are protected by an attesting entity who is trusted by the receiver. This is absolute not the case in our tests. The assertion isn't protected at all. The empty ds:Signature element in the wsse:Security element doesn't protect any thing and even when we totally remove the ds:Signature tag in the assertion, we're granted access.
It seems like the purpose of the "SAML - Verify WSS 1.0 Token" step isn't to validate the confidentiality of the saml assertions and only grant access if the saml assertions is correct. It is possible to freely change the tokens and then be granted access. I think we need some more steps in WSM before the saml validation step, but I don't know which.
We'll like to know if any one knows how to use this "SAML - Verify WSS 1.0 Token" step, to achieve a secure access to protected service. Do we need some pre/post step to achieve a satisfying level of security, do we need to make our own custom step or just used another security product?
Regard
Jacob
Edited by: wmjaboj on 2009-06-10 01:42

hi jacob
looks like you have successfully configured the client side ; I am struggling in that itself. I am calling a secure web-service and I want to use saml token profile 1.1. I am using wls 10.3 and I am getting an error Unable to add signature .
Can you help me with the configuration at the client side ?
Thanks
Regards
Sanyam

Problem with signed SAML assertion and Web Services Manager

Folks,
I’m having some issues trying to generate a proper signed SAML assertion using JDeveloper 10.1.3. I am securing a java proxy class using the wizard as described in http://www.oracle.com/technology/products/jdev/howtos/1013/wssecure/10gwssecurity_howto.html .
On the OWSM side, I have a service that I am securing with SAML - Verify WSS 1.0 Token. If I set the "Allow signed assertions only" property to false I can complete the service call. However, when it is set to true I am receiving the following fault: javax.xml.rpc.soap.SOAPFaultException: SAML token verification failed.
When I examine the message going to OWSM in a packet analyzer, it is missing the signature in the SAML assertion. The <saml:Assertion> tags looks like:
      <saml:Assertion MajorVersion="1" MinorVersion="1"
                      xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
                      xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
                      AssertionID="yM0oqZgF0N1a1td6yzKgOQ22"
                      IssueInstant="2007-01-23T17:15:27Z"
                      Issuer="HealthMarkets_s3">
        <saml:Conditions NotBefore="2007-01-23T17:15:27Z"
                         NotOnOrAfter="2007-01-24T17:15:27Z"/>
        <saml:AuthenticationStatement AuthenticationInstant="2007-01-23T17:15:27Z"
                                      AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
          <saml:Subject>
            <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">client_s3</saml:NameIdentifier>
            <saml:SubjectConfirmation>
              <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod>
            </saml:SubjectConfirmation>
          </saml:Subject>
        </saml:AuthenticationStatement>
      </saml:AssertionI have selected the Sign Outbound Messages in step 3 of the Secure Web Proxy Wizard. This step uses the DSA-SHA1 algorithm.
Any help is greatly appreciated.
Thanks in advance,
Joseph

Thanks for the response. I am not using any pages for this application yet... just calling the web service from SOAP UI or any Web Service testing tool causes the problem.
All that has to be done to replicate it is to build a simple EJB 3.0 JPA bean using the entities from tables wizard and then add named query as follows:
@NamedQuery(name = "BomHeader.findByDesc", query = "select o from BomHeader o where o.bomDesc like :p_bomDesc")
then build a session bean with the wizard that includes the JPA persistence unit and the entity and subsequently use the wizard to wrap the session bean in a web service.
The whole replication process should take 5 minutes if you have some database tables to work with. It breaks when the web service is called.
Thanks in advance

Problem signing SAML assertion

Folks,
I’m having some issues trying to generate a proper signed SAML assertion using JDeveloper 10.1.3. I am securing a java proxy class using the wizard as described in http://www.oracle.com/technology/products/jdev/howtos/1013/wssecure/10gwssecurity_howto.html .
On the OWSM side, I have a service that I am securing with SAML - Verify WSS 1.0 Token. If I set the "Allow signed assertions only" property to false I can complete the service call. However, when it is set to true I am receiving the following fault:
javax.xml.rpc.soap.SOAPFaultException: SAML token verification failed.
When I examine the message going to OWSM in a packet analyzer, it is missing the signature in the SAML assertion. The <saml:Assertion> tags looks like:
      <saml:Assertion MajorVersion="1" MinorVersion="1"
                      xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
                      xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
                      AssertionID="yM0oqZgF0N1a1td6yzKgOQ22"
                      IssueInstant="2007-01-23T17:15:27Z"
                      Issuer="HealthMarkets_s3">
        <saml:Conditions NotBefore="2007-01-23T17:15:27Z"
                         NotOnOrAfter="2007-01-24T17:15:27Z"/>
        <saml:AuthenticationStatement AuthenticationInstant="2007-01-23T17:15:27Z"
                                      AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
          <saml:Subject>
            <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">client_s3</saml:NameIdentifier>
            <saml:SubjectConfirmation>
              <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod>
            </saml:SubjectConfirmation>
          </saml:Subject>
        </saml:AuthenticationStatement>
      </saml:Assertion>I have selected the Sign Outbound Messages in step 3 of the Secure Web Proxy Wizard. This step uses the DSA-SHA1 algorithm.
Any help is greatly appreciated.
Thanks in advance,
Joseph

I do believe that JDev will produce a deployment descriptor that contains the WS-Security policy information. Can you post this? It should look something like this:
<oracle-webservice-clients>
<webservice-client>
<saml-token>
<signature-methods>RSA-SHA1</signature-methods>
</saml-token>
</webservice-client>
</oracle-webservice-clients>

Customizing OWSM 11g SAML policy

Hi,
The current OWSM SAML policy validates only one token against Identity store.
Our requirement is to validate against couple of atributes, is there any option available in existing policy or do we need to write custom policy extending the exisitng policy.
Any pointers on this will be more helpfull.
Thanks,
Sowmya

me too am facing same problem..did you manage to solve this?
please suggest..

Getting Invalid SAML token error while trying to access wls9.2 webservice

Hi,
I am using wss4j at the client side as SAML token issuer to add saml assertion to the soap envelop whose target is a webservice deployed in a aqua logic service bus 2.6. But at the server side i.e wls9.2, i am getting following exception
weblogic.xml.crypto.wss.SecurityTokenValidateResult@326f6a[status: false][msg The SAML token is not valid.]</faultstring></soapenv:Fault></soapenv:Body></soapenv:Envelope>
weblogic.xml.crypto.wss.WSSecurityException: Security token failed to validate. weblogic.xml.crypto.wss.SecurityTokenValidateResult@326f6a[status: false][msg The SAML token is not valid.]
at weblogic.xml.crypto.wss.SecurityImpl.unmarshalAndProcessSecurityToken(SecurityImpl.java:476)
at weblogic.xml.crypto.wss.SecurityImpl.unmarshal(SecurityImpl.java:392)
This error seems to be coming during unmarshalling of soap envelop which is run before request goes to SAML Identity Assertion provider V1. Certificates are properly configured at both client and server side so it seems that generated SAML assertion is not compliant with weblogic 9.2 unmarshalling process.
Has anyone got any solution for this problem. I am not exactly looking for full SSO configuration at the weblogic side so I have not set any credential mapper (which is also a saml issuer). Nor have i done any setting related with SSO on weblogic.
Any idea will really be helpful in this regard.
Thanks.

In what version of Oracle?
I see a couple of problems assuming you are working with a currently supported version:
1. Never grant CONNECT to anyone: Ever. Grant CREATE SESSION.
2. GRANT CREATE TABLE to AQ;
Go to Morgan's Library at www.psoug.org and look at AQ Demo 1. You should have no problem cutting and pasting your way to where you are trying to go.

Passing SAML Tokens to Webservice

Hi All
I have to create a webservice client which passes
Username token, SAML1.1 , 2 , X509 Tokens.
My experience runs low on webservices.
Kindly point to some documents, which specifies
the way to incorporate these token to the webservice call.
Thanks in advance.
Shaan

One method to accomplish this is to leverage an STS to issue security tokens. These security tokens can then be placed into the WS-Security headers of the SOAP requests generated by your web service client. Ping Identity has a product called PingTrust. It is an STS that can issue SAML 1.x, SAML 2.0 and custom tokens, and validate SAML 1.x, SAML 2.0, UserName/Password, Kerberos, X.509 and custom tokens. The product includes SDK;s and JAX-RPC security interceptors that can be used by the application developer to integrate with PingTrust.

OWSM POlicy -11g

Hi All,
We are working on attaching OWSM policies of SOA suite 11g to secure the composites.
Attached 'oracle/wss10_saml_token_service_policy' to the composite keeping configurations as default in saml login module.
When we are trying to test this composite with the below payload
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="Id-00000127b711fabc-0000000001bda657-2" IssueInstant="2010-04-01T01:52:41Z" Issuer="www.oracle.com" MajorVersion="1" MinorVersion="1"> <saml:Conditions NotBefore="2010-04-01T01:52:41Z" NotOnOrAfter="2010-04-06T01:52:41Z"/> <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified" AuthenticationInstant="2010-04-01T01:52:41Z"> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">orcladmin</saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> <saml:AttributeStatement> <saml:Attribute Name="username" NameFormat="www.oracle.com"> <saml:AttributeValue>weblogic</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="password" NameFormat="www.oracle.com"> <saml:AttributeValue>Password1</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> </wsse:Security> </soap:Header> <soap:Body> <cli:process xmlns:cli="http://xmlns.oracle.com/UserProvisioning_jws/Project1/BPELProcess1"> <cli:input>abc</cli:input> </cli:process> </soap:Body> </soap:Envelope>
it is throwing an error
OWSM Policy Fault : FailedAuthentication : The security token cannot be authenticated.
Do we need to make any changes in the input payload or configuration files.
Any pointers on the same will be more helpfull.
Thanks,
Sowmya

Ok got it! Just followed the oracle documentation and copied it in below path and Jdev 11.1.1.4 picked it up!
C:\Users\Amit\AppData\Roaming\JDeveloper\system11.1.1.4.37.59.23\DefaultDomain\oracle\store\gmds\owsm\policies (not copying it within oracle folder within policies as its a custom policy)
Strange, I have Jdev 11.1.1.3 in office and it doesnt pick up the policy but Jdev 11.1.1.4 (at home) picks it up without a problem.
is this a bug in Jdev 11.1.1.3 or my jdev in offic is corrupt?

OWSM: SAML Verify WSS 1.0 Token

Similar Messages

Maybe you are looking for