SAML sender-vouches using SSL

Hi,
I have an WLS 9.2 sending a SOAP with SAML:
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="0">
<Assertion AssertionID="cb5d35763849418c060580753c16b334" IssueInstant="2008-12-03T09:27:59.121Z" Issuer="ISSUER_URL" MajorVersion="1" MinorVersion="1" xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">
<AuthenticationStatement AuthenticationInstant="2008-12-03T09:27:59.121Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified">
<Subject>
<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="notRelevant">USER_NAME</NameIdentifier>
<SubjectConfirmation>
<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
</AuthenticationStatement>
<AttributeStatement>
<Subject>
<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="notRelevant">USER_NAME</NameIdentifier>
<SubjectConfirmation>
<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
<Attribute AttributeName="Groups" AttributeNamespace="urn:bea:security:saml:groups" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<AttributeValue>XX_ATN_X509_HTTPS</AttributeValue>
<AttributeValue>XX_SERVER</AttributeValue>
<AttributeValue>XX_GROUP</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>
</wsse:Security>
I have configured a standard WLS 9.2 as destination. It looks like it understands the SAML token. But I get this SOAP response:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<soapenv:Fault xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<faultcode>wsse:InvalidSecurityToken</faultcode>
<faultstring>Security token failed to validate. weblogic.xml.crypto.wss.SecurityTokenValidateResult@1a2f279[status: false][msg The SAML token is not valid.]</faultstring>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
On the console I see this exception:
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode)
weblogic.xml.crypto.wss.WSSecurityException: Security token failed to validate.
weblogic.xml.crypto.wss.SecurityTokenValidateResult@1be496b[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)
at weblogic.xml.crypto.wss.SecurityImpl.unmarshal(SecurityImpl.java:338)
at weblogic.xml.crypto.wss.api.WSSecurityFactory.unmarshalAndProcessSecurity(WSSecurityFactory.java:65)
at weblogic.wsee.security.WssServerHandler.processRequest(WssServerHandler.java:35)
at weblogic.wsee.security.WssHandler.handleRequest(WssHandler.java:72)
at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:127)
at weblogic.wsee.ws.dispatch.server.ServerDispatcher.dispatch(ServerDispatcher.java:85)
at weblogic.wsee.ws.WsSkel.invoke(WsSkel.java:80)
at weblogic.wsee.server.servlet.SoapProcessor.handlePost(SoapProcessor.java:66)
at weblogic.wsee.server.servlet.SoapProcessor.process(SoapProcessor.java:44)
at weblogic.wsee.server.servlet.BaseWSServlet$AuthorizedInvoke.run(BaseWSServlet.java:173)
at weblogic.wsee.server.servlet.BaseWSServlet.service(BaseWSServlet.java:92)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3231)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2002)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1908)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1362)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
weblogic.xml.crypto.wss.WSSecurityException: Security token failed to validate.
weblogic.xml.crypto.wss.SecurityTokenValidateResult@1a2f279[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)
at weblogic.xml.crypto.wss.SecurityImpl.unmarshal(SecurityImpl.java:338)
at weblogic.xml.crypto.wss.api.WSSecurityFactory.unmarshalAndProcessSecurity(WSSecurityFactory.java:65)
at weblogic.wsee.security.WssServerHandler.processRequest(WssServerHandler.java:35)
at weblogic.wsee.security.WssHandler.handleRequest(WssHandler.java:72)
at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:127)
at weblogic.wsee.ws.dispatch.server.ServerDispatcher.dispatch(ServerDispatcher.java:85)
at weblogic.wsee.ws.WsSkel.invoke(WsSkel.java:80)
at weblogic.wsee.server.servlet.SoapProcessor.handlePost(SoapProcessor.java:66)
at weblogic.wsee.server.servlet.SoapProcessor.process(SoapProcessor.java:44)
at weblogic.wsee.server.servlet.BaseWSServlet$AuthorizedInvoke.run(BaseWSServlet.java:173)
at weblogic.wsee.server.servlet.BaseWSServlet.service(BaseWSServlet.java:92)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3231)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2002)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1908)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1362)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
What do I need to configure on the destination server so that this SAML token is correctly validated?
My understanding is that I use a SAML token with sender-vouches for that the trust is based on the SSL connection. Is my understanding correct?
I have configured 2way-SSL and this works fine between the two machines. Do I need additional certificates on the destination side?
Thanks
Jochen

Hi Bethune,
you replied to a request that I posted in December 2008.
Hopefully you are still in this business ... :)
I need to consume a SAML 1.1 Sender-Vouches assertion on WLS 10.3 now.
The 2way-SSL is established fine and I am able to send the SOAP request with the SAML 1.1.
On the sending server I see that 2way SSL is fully established and the SOAP is sent to the destination.
I get this response:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<env:Fault xmlns:fault="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<faultcode>fault:MustUnderstand</faultcode>
<faultstring>MustUnderstand header not processed '{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security'</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
The above means nothing is configured to process the SAML 1.1 Assertion.
But I did the following:
Security Realm > myrealm > Providers
I have added: SAMLIdentityAsserterV2
SAMLIdentityAsserter > Managment > Asserting Party
I have added an Asserting Party
- WSS/Sender-Vouches
- Enabled
- Issuer URI: "the one used in the SAML assertion"
- Target URL: https://localhost:7002/webservice/WebServiceOpteration (URL used to call the webservice)
I am not quite sure if the TargetURL is correct? What is the format here?
For me it looks pretty much complete but still I get this mustUnderstand issue.
Looks like my config is ignored. What might I have missed?
I have enabled debug for saml and saml2 but I do not see any SAML related entries in the output on the console.
Do you have any ideas? It was working on WLS 9.2 but now I am stuck on WLS 10.3.
Thanks for your support
Jochen

Similar Messages

SAML Sender Vouches Assertion in ABAP only environment

All u2013 apologies for a length postu2026
subject: Standard logon - SAML Authentication (logon using SAML).
We are testing if an external app u2013 like Oralce (consumer), can render a web service via SAML assertion into an AS ABAP (provider) environment. Per OSS note 1254821, we have setup a trusted environment, and were able to successfully test a bapi function via Certificate Authentication (logon using a client certificate), one of the standard logons.
This test validates that the SOAP message can be processed through SAP, from the secured transport layer to decrypting and processing the SOAP message.
When we move to test the SAML assertion piece, we are not able to find the logon of u201CSAML Authenticationu201D via the standard logon through trnx SICF.
We nonetheless moved to test with all the available logon options without success:
1     Fields Authentication
2     SSO Authentication
3     Basic Authentication
4     SAP Authentication
5     Certificate Authentication (we deactivated the USEREXTIDu2019s DN user)
6     Service Authentication
While researching, we come across that there should be a u201CSAML Authenticationu201D standard logon option, yet this is not available in our test system.
Our system information is as follow:
SAP ECC 6.0
SAP_BASIS      700      SAPKB70017
SAP_ABA         700      SAPKA70017
We are testing in an ABAP stack environement.
We have crossed reference with note 1254821, and have satisfied all the requirements.
We expect the standard logon to contain the u201CSAML Authenticationu201D through SICF since we have configured the web service through SOAMANAGER using u201CSAML 1.1. Sender Vouches Assertionu201D.
Question:
Is u201CSAML Authenticationu201D standard logon necessary to facilitate the SAML sender vouches solution (we have only AS ABAP)?
If needed, what configuration, or support pack we need to be on.
Better yet, have anyone out there make it work? If so, please share.
Thanks much,
Alex

Hi Jens,
yes, it's keystore view TicketKeystore. The idea is that a logon ticket trust suffices to get the SAML 1.1 Sender Vouches trust as well.
The next thing you should take care of is to make sure that your SAP Portal system trusts the SAML issuer of your SAML assertion. This is to be configured in NetWeaver Administrator under Configuration Management Security > Trusted Systems. There you add the issuer string of your SAML Assertion into the Trusted Partners section.
Please follow paragraph "Configuring the Trusted Partners (Provider)" on this documentation link for details: http://help.sap.com/saphelp_nw73/helpdata/en/48/b264916b156ff4e10000000a42189b/frameset.htm
Another thing. Please see that for SOAP Web Services SAP (both AS ABAP and AS Java) for Sender-Vouches only SAML 1.1 is supported. Holder-of-key SAML assertions are supported with SAML 1.1 and SAML 2.0.
Regards,
Mathias

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>

Trying SAML sender-vouches, standalone Java client call to service bus.

I've built a standalone Java client using Jax-ws. It produces a wsse header containing both a SAMLAttribute and an optional SAMLAuthentication statement.
I've tried to configure a proxy service on the servicebus (10gR3) using ws-policy (weblogic version, not ws-1.2), configured a SAMLIdentityAsserter (v2), an identity provider partner and a SAMLIdentityNameMapper.
I get the message weblogic.xml.crypto.wss.SecurityTokenValidateResult@ca32f2[status: false][msg The SAML token is not valid.]
when sending SAML assertions which looks valid to me.
If you see something missing or invalid in the SAML, something missing in the configuration or something else, I would be really glad.
All examples are using a SAMLCredentialmapper, but I'm building a standalone client, so a weblogic SAMLCredentialMapper is out of the question (?).
request header:
<S:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" S:mustUnderstand="1">
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:xs="http://www.w3.org/2001/XMLSchema" AssertionID="1246342701761" IssueInstant="2009-06-30T06:18:21.683Z" Issuer="http://openuri.org/service/customer/contact/contactInformationService" MajorVersion="1" MinorVersion="1">
<saml:Conditions NotBefore="2009-06-30T06:17:21.683Z" NotOnOrAfter="2009-06-30T07:18:21.683Z"/>
<saml:AuthenticationStatement AuthenticationInstant="2009-06-30T06:18:21.683Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified">
<saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" NameQualifier="sb1sk">uid=vsb,ou=smn</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>
response:
<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:InvalidSecurityToken</faultcode>
<faultstring>Security token failed to validate. weblogic.xml.crypto.wss.SecurityTokenValidateResult@1061c5e[status: false][msg The SAML token is not valid.]</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
If the client leaves out the wsse:security element in the header, the service complains
<faultstring>No Security header in message but required by policy.</faultstring>
The SAMLIdentity name mapper is never loaded at all (checked by logging at class loading)
The configuration in the Identity provider partner:
audience uri: target:*:/
issuer uri: /service/customer/contact/contactInformationService (also tried with a unique string equal to what the client sends)
virtual user: enabled
confirmation method: sender-vouches
I am not using any certificates (tryed both with and without)
Policy in use for the proxy service:
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
wsu:Id="samlSV"
>
<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>sender-vouches</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
</wsp:Policy>
Stacktrace:
weblogic.xml.crypto.wss.WSSecurityException: Security token failed to validate. weblogic.xml.crypto.wss.SecurityTokenVal
idateResult@a4fc20[status: false][msg The SAML token is not valid.]
at weblogic.xml.crypto.wss.SecurityImpl.unmarshalAndProcessSecurityToken(SecurityImpl.java:630)
at weblogic.xml.crypto.wss.SecurityImpl.unmarshalChildren(SecurityImpl.java:556)
at weblogic.xml.crypto.wss.SecurityImpl.unmarshalInternal(SecurityImpl.java:448)
at weblogic.xml.crypto.wss.SecurityImpl.unmarshal(SecurityImpl.java:416)
at weblogic.xml.crypto.wss.api.WSSecurityFactory.unmarshalAndProcessSecurity(WSSecurityFactory.java:66)
at weblogic.wsee.security.WssServerHandler.processRequest(WssServerHandler.java:35)
at weblogic.wsee.security.WssHandler.handleRequest(WssHandler.java:74)
at com.bea.wli.sb.security.wss.WssInboundHandler.processRequest(WssInboundHandler.java:116)
at com.bea.wli.sb.security.wss.WssHandlerImpl.doInboundRequest(WssHandlerImpl.java:201)
at com.bea.wli.sb.context.BindingLayerImpl.addRequest(BindingLayerImpl.java:257)
at com.bea.wli.sb.pipeline.MessageProcessor.processRequest(MessageProcessor.java:66)
at com.bea.wli.sb.pipeline.RouterManager$1.run(RouterManager.java:508)
at com.bea.wli.sb.pipeline.RouterManager$1.run(RouterManager.java:506)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
Edited by: user6080617 on Jun 29, 2009 11:39 PM

Thank you for the tip. I've tried it, the result is below. It suspect something missing in my configuration, but I do not know what.
<WSEE:17>Class of cred is: class weblogic.xml.saaj.SOAPElementImpl<SAMLCredentialImpl.<init>:85>
<WSEE:17>Instantiating SAMLAssertionInfoFactory<SAMLCredentialImpl.<init>:87>
<WSEE:17>Getting SAMLAssertionInfo from DOM Element<SAMLCredentialImpl.<init>:97>
<WSEE:17>Got SAMLAssertionInfo<SAMLCredentialImpl.<init>:117>
<WSEE:17>Assertion ID: 1246358297862<SAMLCredentialImpl.verbose:69>
<WSEE:17>Assertion CM: urn:oasis:names:tc:SAML:1.0:cm:sender-vouches<SAMLCredentialImpl.verbose:70>
<WSEE:17>Assertion Subject: uid=vsb,ou=smn<SAMLCredentialImpl.verbose:71>
<WSEE:17>Assertion Version: 1.1<SAMLCredentialImpl.verbose:72>
<WSEE:17>Attempting assertIdentity<CSSUtils.assertIdentity:310>
<WSEE:17>SAML_TARGET_RESOURCE is: /service/customer/contact/contactInformationService<CSSUtils.assertIdentity:312>
<WSEE:17>Got Principal Authenticator<CSSUtils.assertIdentity:314>
<WSEE:17>Cred type is: SAML.Assertion.DOM, Node: [saml:Assertion: null]<CSSUtils.assertIdentity:320>
<WSEE:17>Exception while asserting identity: javax.security.auth.login.LoginException: [Security:090377]Identity Assertion Failed, weblogic.security.spi.IdentityAssertionException: [Security:090380]Identity Assertion Failed, Unsupported Token Type: SAML.Assertion.DOM<CSSUtils.assertIdentity:325>
<WSEE:17>javax.security.auth.login.LoginException: [Security:090377]Identity Assertion Failed, weblogic.security.spi.IdentityAssertionException: [Security:090380]Identity Assertion Failed, Unsupported Token Type: SAML.Assertion.DOM<CSSUtils.assertIdentity:326>

Which truststore for SAML Sender Vouches signatures in SOAP message

Hi Experts,
I try to consume a Web Service provided by SAP Portal 7.3 EHP 2, which is secured using SAML 2.0.
My intention is to send SAML assertion using the Sender Vouches confirmation method and looking at the sample message from the Wiki and my message side-by-side, I am confident that the message should be understandable for SAP (having the correct signatures etc.)
However, using the Security Troubleshooting Wizard, I collected some traces on the SAP Portal side and I can see that the certificate I use seems to untrusted.
The Exception thrown somewhere near the WSSAMLLoginModule is:
Caused by: javax.security.auth.login.LoginException: com.sap.exception.io.SAPIOException: [com.sap.ASJ.wssec.020359] An exception was thrown during the verify of the SAMLTokenHandler: The certificate Subject DN: ....... is not in the list of trusted certificates.
at com.sap.security.core.server.wssec.jaas.WSSAMLLoginModule.login(WSSAMLLoginModule.java:91)
at com.sap.engine.services.security.login.LoginModuleLoggingWrapperImpl.login(LoginModuleLoggingWrapperImpl.java:254)
at com.sap.engine.services.security.login.ModulesProcessAction.run(ModulesProcessAction.java:65)
... 52 more
I already imported the cert in almost all trust stores. Where do I specify the trusted certs?
Thanks.
Jens

Hi Jens,
yes, it's keystore view TicketKeystore. The idea is that a logon ticket trust suffices to get the SAML 1.1 Sender Vouches trust as well.
The next thing you should take care of is to make sure that your SAP Portal system trusts the SAML issuer of your SAML assertion. This is to be configured in NetWeaver Administrator under Configuration Management Security > Trusted Systems. There you add the issuer string of your SAML Assertion into the Trusted Partners section.
Please follow paragraph "Configuring the Trusted Partners (Provider)" on this documentation link for details: http://help.sap.com/saphelp_nw73/helpdata/en/48/b264916b156ff4e10000000a42189b/frameset.htm
Another thing. Please see that for SOAP Web Services SAP (both AS ABAP and AS Java) for Sender-Vouches only SAML 1.1 is supported. Holder-of-key SAML assertions are supported with SAML 1.1 and SAML 2.0.
Regards,
Mathias

Error in sending mail using ssl server

Hi All
Please help in resolving the below issue i am getting the following error while sending mail. I am using the IMAP server and it is ssl configured.
DEBUG: setDebug: JavaMail version 1.4ea
DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun Microsystems, Inc]
DEBUG SMTP: useEhlo true, useAuth false
DEBUG SMTP: trying to connect to host "mail.test.com", port 465, isSSL true
DEBUG SMTP: exception reading response: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: subject/issuer name chaining check failed
javax.mail.MessagingException: Exception reading response;
nested exception is:
     javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: subject/issuer name chaining check failed
     at com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:1462)
     at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1260)
     at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:370)
     at javax.mail.Service.connect(Service.java:275)
     at com.test.test.JavaMailApp2.main(JavaMailApp2.java:59)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: subject/issuer name chaining check failed
     at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)
     at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)
     at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)
     at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source)
     at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)
     at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
     at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
     at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)
     at com.sun.mail.util.TraceInputStream.read(TraceInputStream.java:97)
     at java.io.BufferedInputStream.fill(Unknown Source)
     at java.io.BufferedInputStream.read(Unknown Source)
     at com.sun.mail.util.LineInputStream.readLine(LineInputStream.java:75)
     at com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:1440)
     ... 4 more
Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: subject/issuer name chaining check failed
     at sun.security.validator.PKIXValidator.doValidate(Unknown Source)
     at sun.security.validator.PKIXValidator.doValidate(Unknown Source)
     at sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
     at sun.security.validator.Validator.validate(Unknown Source)
     at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(Unknown Source)
     at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
     at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
     ... 17 more
Caused by: java.security.cert.CertPathValidatorException: subject/issuer name chaining check failed
     at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(Unknown Source)
     at sun.security.provider.certpath.PKIXCertPathValidator.doValidate(Unknown Source)
     at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(Unknown Source)
     at java.security.cert.CertPathValidator.validate(Unknown Source)
     ... 24 moreBelow is the source code of the program.
package com.test.test;
import java.security.Security;
import java.util.Properties;
import javax.mail.Authenticator;
import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.NoSuchProviderException;
import javax.mail.PasswordAuthentication;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.AddressException;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;
public class JavaMailApp {
     public static void main( String[] args )
          String d_email = "[email protected]";
          String d_uname = "ots.support";
          String d_password = "password";
          String d_host = "mail.test.com";
          String d_port = "465"; //465,587
          String m_to = "[email protected]";
          String m_subject = "Testing";
          String m_text = "Hey, this is the testing email.";
          Properties props = new Properties();
          props.put("mail.smtp.user", d_email);
          props.put("mail.smtp.host", d_host);
          props.put("mail.smtp.port", d_port);
          props.put("mail.smtp.starttls.enable","true");
          props.put("mail.smtp.debug", "true");
          props.put("mail.smtp.auth", "true");
          props.put("mail.smtp.socketFactory.port", d_port);
          props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory");
          props.put("mail.smtp.socketFactory.fallback", "false");
          SMTPAuthenticator auth = new SMTPAuthenticator();
          Session session = Session.getInstance(props, auth);
          session.setDebug(true);
          MimeMessage msg = new MimeMessage(session);
          try {
               msg.setText(m_text);
               msg.setSubject(m_subject);
               msg.setFrom(new InternetAddress(d_email));
               msg.addRecipient(Message.RecipientType.TO, new InternetAddress(m_to));
               Transport transport = session.getTransport("smtps");
               transport.connect(d_host, 465, d_uname, d_password);
               transport.sendMessage(msg, msg.getAllRecipients());
               transport.close();
          } catch (MessagingException e) {
               // TODO Auto-generated catch block
               e.printStackTrace();
public class SMTPAuthenticator extends Authenticator{
     public PasswordAuthentication getPasswordAuthentication()
        return new PasswordAuthentication("[email protected]", "password");
}I have also added the certificate to my keystore using the following command and still i am facing this issue.
keytool -import -trustcacerts -alias root -file mail_test_com.crt -keystore keystore.jks
Add to fierof2's Reputation

this is where i created the keystore.jks file
I navigated to the location C:\Program Files\Java\jdk1.6.0_13\bin in command prompt and typed the following command to create the keystore
keytool -import -trustcacerts -alias root -file mail_test_com.crt -keystore keystore.jksI was asked to set the password for keystore and then i was asked the question "Trust this certificate? [no]:" for which i gave yes.
If this is not the right place to create the keystore.jks can you please tell me what is correct location to create the keystore file.

Can't get sender-vouches SAML SSO (webservice) to work

Hi,
I have a small test configuration, with a webservice and a webservice client developed using Workshop. This is on WebLogic 9.2.
I am trying to get the sender-vouches SAML SSO profile to work between my webservice client and the webservice, but I keep getting an "Unable to add identity to token" error.
I enabled debugging, and it looks like the problem is that the webservice client side is trying to check to see if the relying party is in the "relying party mapping", but not finding a match, even though I do have the RP URL correctly in the SAML Credential Mapper->Management->Relying Parties configuration.
I have been trying all kinds of variations, changing the URL, etc., but to no avail.
Has anyone been able to get this profile working between webservice client and webservice, and if so, any ideas what might be the problem?
Thanks,
Jim

P.S. Here's the log output:
####<Jun 17, 2007 3:25:32 PM EDT> <Debug> <SecuritySAMLCredMap> <WD5WLS92A> <AdminServer> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1182108332447> <000000> <SAMLCredentialMapperV2: getCredentials: Subject initiator>
####<Jun 17, 2007 3:25:32 PM EDT> <Debug> <SecuritySAMLCredMap> <WD5WLS92A> <AdminServer> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1182108332447> <000000> <SAMLCredentialMapperV2: getCredentials(Subject): getCredentialInternal() called>
####<Jun 17, 2007 3:25:32 PM EDT> <Debug> <SecuritySAMLCredMap> <WD5WLS92A> <AdminServer> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1182108332447> <000000> <SAMLCredentialMapperV2: getCredentialInternal(): requestor = Subject: 1
     Principal = class weblogic.security.principal.WLSKernelIdentity("<WLS Kernel>")
>
####<Jun 17, 2007 3:25:32 PM EDT> <Debug> <SecuritySAMLCredMap> <WD5WLS92A> <AdminServer> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1182108332517> <000000> <SAMLCredentialMapperV2: getCredentialInternal(): initiator = Subject: 2
     Principal = class weblogic.security.principal.WLSUserImpl("samltest1")
     Principal = class weblogic.security.principal.WLSGroupImpl("TestGroup")
>
####<Jun 17, 2007 3:25:32 PM EDT> <Debug> <SecuritySAMLCredMap> <WD5WLS92A> <AdminServer> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1182108332517> <000000> <SAMLCredentialMapperV2: getCredentialInternal(): resource = (null)>
####<Jun 17, 2007 3:25:32 PM EDT> <Debug> <SecuritySAMLCredMap> <WD5WLS92A> <AdminServer> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1182108332517> <000000> <SAMLRPConfigManager.findPartnerInTargetMap():Searching with key 'sender-vouches:http://localhost:7001/ServicesWeb/MailingListService'>
####<Jun 17, 2007 3:25:32 PM EDT> <Debug> <SecuritySAMLCredMap> <WD5WLS92A> <AdminServer> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1182108332517> <000000> <SAMLRPConfigManager.findPartnerInTargetMap():No partner found>
####<Jun 17, 2007 3:25:32 PM EDT> <Debug> <SecuritySAMLCredMap> <WD5WLS92A> <AdminServer> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1182108332517> <000000> <SAMLCredentialMapperV2: getCredentialInternal(): No matching relying party found>
Note the "No partner found" msg...
Jim

Jax-ws ws client with saml 1.1 sender vouches policy

Hi,
In wls 10.3 I defined a SAML source site , now I want to use the sender voucher policy on a webservice. So far so good.
Now I want to generate a jax-ws proxy client, but there are no sample how to use this policy in java, only some wlst examples.
Is there some more information how to do this.
thanks Edwin

hi
This is not an answer to your question but a question since you have created a SAML Source Site in wls 10.3.
Have you been able to use SAML Authenication from a weblogic client to web-service on different domain ?
I am not able get this work ?
I am done the following
SAML relying party on SAML Credential Mapper on domain1
with
target url =endpoint of webservice at domain2
and asserting Party on SAML Identity Asserter
with target url= relative url of the web service.
At Source Site , I saw that wls is not attaching any security information in the SOAP header .
Can someone Help me with Configuration .
The end goal is to access a secure web-service
Thanks
Sanyam

HTTPS authentication using SSL in SOAP Sender adapter

Hi,
We are currently doing a SOAP to RFC synchronous scenario in PI 7.0. Our client wants to ensure that the data security is maintained at the transport level. So, we have planned to implement the HTTPS without client authentication using SSL certificates. Our Basis team has promised us that they will take care of the cerficate generation and installation part in the server. Now i am confused at the PI communication channel setup level.
1) Do i have to specify the certificate installed path in the channel or in any other object ? If so, where do i have to configure the path ?
2) What is the exact path that has to be carried by a PI developer once the certificates are installed in the server ?
I have attached my communnication channel screenshot below,
http://i41.tinypic.com/mk49h.jpg
Please let me know what i have to configure in the Sender SOAP channel to receive data securely once the certificates are installed in the system.
Thanks & Regards,
Sherin Jose P

Hi,
1.for transport level security you should assign the HTTPS connection created in SM59 to the SOAP communication channel.
The HTTPS connection should use the certificates imported in t-code STRUST.
have you seen below thread,
SSL / X.509 In SOAP Sender/Receiver Adapter
Please go through below blog,
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/b2e7020d-0d01-0010-269c-a98d3fb5d16c?overridelayout=true
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/60ff2883-70c5-2c10-f090-a744def2ba66?QuickLink=index&overridelayout=true
http://help.sap.com/saphelp_nwpi71/helpdata/de/14/ef2940cbf2195de10000000a1550b0/content.htm
2. you nedd to check the message flow between the sender and receiver through PI .
regards,
ganesh.

Mail reluctant to send after having selected 'Use SSL' in server settings

I read yesterday afternoon on the security tips page [http://discussions.apple.com/thread.jspa?threadID=121760] the recommendation to ensure SSL is used for sending email. When I discovered the option to use SSL was not selected on the settings panel for my outgoing server, I selected it. But now, each time I attempt to send an email, Mail immediately tells me that it can't send using that server, and presents me with other choices. When I insist on using that server, it will try again and, most times, will then be successful... but sometimes several attempts are needed before the mail is sent.
Is there something I can do to avoid having to re-try each time I send an email?
Thanks!

is the port setting you mentioned on my end or theirs?
Well, it's on their end, but you must match whatever they set it to, sending Mail could be... ports 25, 587 and 465. Port 587 has to be SSL, and port 465 is enforced TLS-wrapped and is generally used by Outlook users.
Receiving Mail...
IMAP is port 143
IMAP-SSL is port 993
POP is port 110
POP-SSL is port 995

Can send to SMTP using SSL from everywhere but home!

Hi all,
This is a very very peculiar problem and god knows I have had my share of strange problems with computers but I think this one tops them all. The situation is the following:
I would like to be able to send email using my work SMTP server which requires a secured SSL connection. I have the correct configuration in Mail. When I am at work, I am able to send emails with no problems. When I am anywhere else (free wifi at mcDonalds, friend's home,..) I can send no problem....But I CAN'T SEND FROM HOME!!
I get an error message telling me to try another server. I have tried pinging the server from home and there is no problem there. I have also tried Outlook Express running on Parallels on the same machine and from home and there is also no problem: the emails go through!
If anyone has any suggestions, I would really appreciate it as I am about to go crazy!
Thanks!

K.,
Try a test by creating a New User Account, and as that New User launch Mail and try setting up this work related account, and then test sending. See the following if not familiar with adding a new user account:
http://docs.info.apple.com/article.html?path=Mac/10.5/en/8235.html
The reason for doing this is to test the Mail app itself, and not to permanently switch to a new user account. If this account is a POP account, be sure to select for it to leave messages on the server after download. That would not be an issue with type IMAP.
Ernie

SAML2.0 for web services - sender-vouches scenario

We would like to configure this scenario using SAML2.0 assertion tickets. We are on ECC 6 EhP6.
Configuration in SAML2 has been completed - no WS security policy has been configured in order to support the sender-vouches scenario.
WSS_SETUP has run to use SAML.
When configuring the web services we are using https for transport and SAML for authentication - the wsdl generated in this case references SAML1.1 and as result we get an error of Wrong token type received. Endpoint expects SAML 1.1 token.
The question is: can SAML2.0 be used for sender-vouches scenarios or not?
Any input or help would be greatly appreciated.
Thank you,
Miklos

Hi Miklos,
Yes you can use SAML2.0 for Sendor-vouches scenarios.
Please see the below link for configuration process:
http://help.sap.com/saphelp_nw73/helpdata/en/b5/014086933d4576bba1b4c7e9533f4b/content.htm
I hope it will be helpful for you.
Regards,
Gourav
Message was edited by: Gourav Kumar Jena

SAML1.1 Assertion (Sender Vouches) policy

Hi,
I am trying to write SAML1.1 Assertion (Sender Vouches) policy that will not be used over HTTPS and will not use the message signing and encryption (I do not want to use the standard policies Wssp1.2-2007-Saml1.1-SenderVouches-Https.xml and Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml for these reasons). Functionall this policy should be like:
<?xml version="1.0"?>
<wsp:Policy ........................>
<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>sender-vouches</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
</wsp:Policy>
But the above policy can be used with JAX-RPC only (I plan to use new policy in JAX-WS web services).
Could someone help me with this task?
Any help will be appreciated.
Regards,
Alex

Hi,
Thanks for the reply. Did you tell about the creation of the service request (SR) with Oracle support? May be I do not understand something, but this is not the Weblogic problem. I am just trying to create the custom SAML policy. Or may be you meant that Weblogic (or OASIS WSS1.0 SAML10 schema) doesn't normally support SAML assertion without the encryption (transport or message)?
Regards,
Alex

Loss of sending email using WIFI

As of this morning 8-20-08, after updating to 2.02, I no longer am able to send emails using my own wireless network. Previously this was no problem. Neither Fido or Apple have any idea of what I am talking about. Fido washed their hands as they do not support WIFI. How convenient, they sell the phone and charge for the service but do not support it. Videotron, my ISP, thinks the issue is my wireless router but I can send via gmail so that's out. I resovled the problem by configuring my accounts to use my gmail smtp server as a second option and now the spinning wheel is short lived and messages are sent.
I'm sorry to say that I had fallen for all the hype about Apple but truth is they are but a Microsoft wannabe.
Disinchanted

So here's the wierd thing.
I was having the same problems. Set up SMTP for Videotron when at home using relais.videotron.ca SMTP with no authenticationon port 25 & all was good in the world. However when I went out, bang. Nothing. Couldn't send a mail for love nor money.
Thought aboutit & changed settings to use relais.videotron.ca SMTP, but this time using authentication of vltl** / password credentials with no SSL (Videotron doesn't use SSL) and again everything was fine. Of course, when I got home again, bang. Everything fell over & no more mail sending foe me!
So I figure, when I'm at home I'm on my trusted network at port 25, I don't need authentication and all is good, but when I'm out i'm seen as potential SPAM by port 25 on videotron & get blocked.
Tried using port 587 instead when for both home & mobile but had no luck either.
Then a strange thing happened. I'd resolved to having to set up 2 SMTP servers on my iPhone & switching between the two based on where I was. Pain in the a**, but there's always a trade off for early adopter technology So I set up my primary SMTP to use port 25 with no authentication, and a secondary server to use the same relais.videotron.ca outgoing server, but this time WITH authentication using vltl** \ password credentials.
After a walk to the shop when I'd been on my secondary SMTP server (successfully sending & recieving) I came home & inadvertantly forgot to swith back to my primary SMTP. Recieved a mail & then responded with no problem!
Net result, I now have a permanently switced off primary server & a permanently switched on secondary server which uses relais.videotron.ca details with vltl** \ password authentication credentials active (like I did on my old silver iPhone) & all is good in the world, both at home & out mobile, both for sending & recieving!
Will field test some more tomorrow but it may be a 2.0.2 bug where ther primary server details fcuk up whereas the secondary server details are stable.
So long as it works, who cares!
Jof

Cannot get or send mail using Apple Mail on iPhone and iPad

Everyone in my household cannot get or send mail on their Apple Mail for iPad and iPhone. We all get the same message: "The user name or password for [account] is incorrect." This just started happening yesterday afternoon. No problems before that. I called my hosting company and Apple, and both blamed the other. My Apple system is always updated, so I have the latest version of Maverick. Had no problems with it up until now.
However, I awoke this morning to find downloaded emails in the same program, but when I go to "get mail," it says the same thing, and still won't allow me to send or receive.
Here's the kicker. I also use Gmail with the exact same accounts (yes, I need both since Apple Mail does things that Gmail doesn't, and vice versa). No problem! I get all my emails and can send with no problem. So, my hosting company claims it can't be them (makes sense). It only happens using Apple Mail, and I have several email addresses. None of them work (other than the strange phenomena of suddenly getting some of them downloaded for no apparent reason).
What do I do from here? I've changed passwords, deleted and tried to set up my emails, only to get the message that they probably will not work. And they don't. I have shut down and restarted my iPad and iPhone, to no avail.
Thank god for my Gmail account, or my business would be closed.
Again, this is happening on four devices in my home: 2 iPads and 2 iPhones.

I have a comcast account I use on my phone and use it for receiving and sending mail. When you look at the account in settings, you need to check each of these
incoming mail server: mail.comcast.net
username: the part of your email address before the @
password: your password
outgoing mail server: smtp.comcast.net
Under Advanced
Use SSL: On
Authentication: Password
Server Port: 995
If you cannot make it work from changing settings in the account, delete the account and start over. Use the "Other" setting when starting the account. It is a POP3 account and make the entries I gave you. Once you do that, it should check the entries and validate the account. You shouldn't have any trouble from there. Those settings will work from either the iPhone on cell, or wireless. Mine will even work when I'm at home on my wireless there, which is on the Comcast network.
Hope that helps you.

SAML sender-vouches using SSL

Similar Messages

Maybe you are looking for