We Use OpenAM version 13.0.0
and we faced the following error during using urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
ERROR: spAssertionConsumer.jsp: SSO failed. com.sun.identity.saml2.common.SAML2Exception: No local user being mapped. at com.sun.identity.saml2.profile.SPACSUtils.processResponse(SPACSUtils.java:1225) at org.apache.jsp.saml2.jsp.spAssertionConsumer_jsp._jspService(spAssertionConsumer_jsp.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
The hosted SP first uses the NameID map to extract the 'username' from the Subject (that holds the NameID) of the incoming SAML assertion and then use it to search the configured user data stores for an user identity subject (using the configured user search attribute). If this fails, it uses the configured account mapper to extract a 'username' attribute from the attribute statement. Here auto-federation configuration also matters.
--> It depends on the SAML response and OpenAM configuration why you run into this error. It's impossible to tell the root cause without seeing the SAML response and the OpenAM configuration. You may send it to me via (encrypted) email.
Related
We are trying to implement SSO, using OneLogin as the IdP with our Cisco Call Manager cluster using a single agreement for all the servers in the cluster.
This just basically means that our metadata file contains a separate AssertionConsumerService tag for every server in the cluster.
However we are hitting an issue where in the SAML response the Destination is not recognized as valid.
My question would be, in the case of multiple ACS' used, what would the destination field need to look like in the SAML response? Does the IdP need to recognize which consumer the request came from and dynamically change the destination in the response to be the correct one for the specific consumer?
Right now the SAML response looks something like this:
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://<CUCM_2>:8443/ssosp/saml/SSO/alias/<CUCM_2>https://<CUCM_2>:8443/ssosp/saml/SSO/alias/<CUCM_2>https://<IMP_1>:8443/ssosp/saml/SSO/alias/<IMP_1>https://<IMP_1>:8443/ssosp/saml/SSO/alias/<IMP_1>https://<CUCM_1>:8443/ssosp/saml/SSO/alias/<CUCM_1>https://<CUCM_1>:8443/ssosp/saml/SSO/alias/<CUCM_1>" ID="pfx117d2cec-f554-1fba-ff86-8db77b497e35" InResponseTo="s2ded98fb1a7423ea7bb1fcc95cf5c57ae3bf19684" IssueInstant="2019-02-18T16:06:06Z" Version="2.0">
and we get the same jumble for Recipient attribute in SubjectConfirmationData
With a proper cluster, you'd have a single ACS URL and the cluster would manage the user session between cluster members outside of SAML. I've not heard of multiple ACS URLs being used for a single SAML supporting SP. The IdP ( Onelogin ) needs to know specifically where to send the SAML response. I think you'll need to look at your cluster configuration and see whether it can be configured as a endpoint regardless of the cluster instance that initiates the SAML request.
Ah, but Cisco is special, don't you know? :)
I managed to get it working in the meantime and whoever is reading this thread in the future, I can confirm that OneLogin can now support Cisco clusters using a single cluster-wide metadata. But for any other IdP the setup is:
IdP requirements
CUCM only supports NameIDFormat as transient
HTTP-POST and HTTP-Redirect SAML bindings need to be enabled
SAML specification that allows for the definition of multiple AssertionConsumerService tags needs to be supported
Operation
When setting up SSO, within the metadata generated by CUCM if using cluster wide SSO mode, multiple AssertionConsumerService tags are defined. Two for each server in the cluster, one using the POST method and one using Redirect. Each ACS also has an Index tag, that starts at 0. This is sent to the IdP
When trying to authenticate a SAML request is sent to the IdP, within the request the AssertionConsumerServiceIndex field is set to the Index of the server from which the request was generated, as defined in the metadata originally provided to the IdP
The IdP then sends back a SAML response, in which the Destination and Recipient tags are set to match the Location tag from the metadata corresponding to the requesting server
I have a WSO2IS 5.2 acting as a federation hub. The AuthnRequest that it sends to IdP (in this case PingFederate) includes this NameIDPolicy:
<saml2p:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
SPNameQualifier="WSO2IS"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
/>
After logging in at PingFederate it sends back SAML message including this:
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" />
</samlp:StatusCode>
<samlp:StatusMessage>Cannot provide requested name identifier qualified with WSO2IS</samlp:StatusMessage>
</samlp:Status>
I've tried uid and mail NameID values in PingFederate but I always get this response. I would like to try changing the NameIDPolicy format that wso2is sends but have not found a way to do it. I think it should be a SAML:2.0 format.
Only thing I found was "Include NameID Policy" check box in IdP settings but it stays checked even if I uncheck it and save.
How to change the NameIDPolicy format?
UPDATE: I solved the problem by enabling pseudonym identifier at PingFederate and sending username as attribute. Still it would be good to know the answer to my question.
Yes your understanding is correct. You could need to change the NameIDPolicy. You can found it in service provider (SP) creation page. Go to WSO2 IS management console, Home>service Provider>Add> .
After that need to enter the name for SP and click the register button.
Now you are in Service provider configuration page.
GO to Inbound Authentication Configuration>SAML2 Web SSO Configuration>configure.
This page you can configure SAML2 Web SSO configuration and page header show as
Register New Service Provider and go to NameID format change the urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress instead of urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress.
You can found more details from WSO2 documentation [1].
[1] https://docs.wso2.com/display/IS500/Configuring+Single+Sign-On+with+SAML+2.0
Using WSO2 5.1.0. Needs to send SAML assertion like firstName, lastName from WSO2 as IDP to SP. Refer Configuration. User profile do have first name and last name values.
Restarted WSO2, no error in logs. But I don't receive these values in SAML response sent from WSO2 to my Service porvider.
For this, in your Service Provider's SAML Configuration, you need to make sure following two checkboxes are selected.
Enable Attribute Profile
Include Attributes in the Response Always
Then, inside the Claim Configuration section of the Service Provider configuration, you need to add the particular claims you need to receive as Requested Claims. Then these claims will be included in SAML response.
If you want the claims to have a different key name, you can define a custom claim dialect there and provide your own key names for claims.
idp-process.log
ERROR [org.opensaml.ws.security.provider.MandatoryAuthenticatedMessageRule:37] - Inbound message issuer was not authenticated.
shibd.log
ERROR OpenSAML.SOAPClient [109]: SOAP client detected a SAML error: (urn:oasis:names:tc:SAML:2.0:status:Responder) (Message did not meet security requirements)
ERROR Shibboleth.AttributeResolver.Query [109]: attribute authority returned a SAML error
The Shibboleth Authentication process is working properly. The Active Directory server (LDAP) is configured properly to work over SSL, which was verified using LDP.exe. I also coded a simple Java program to try to connect to the Active Directory server over SSL protocol. I was able to connect to the server using port 636, passed user credentials including password, and the server responded properly.
Certificates are already trusted by corresponding JVM cacerts.
Setup instructions are already followed as documented from https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverLDAPDataConnector
However, there is still an error during Attribute query from the Active Directory server. Below are snippet of the configurations.
Any idea as to why there is an error on the Attribute Query?
Thanks.
attribute-resolver.xml
<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
ldapURL="ldaps://WIN-1GB01UK5SL6.VECISADTEST.com"
baseDN="CN=Users,DC=vecisadtest,DC=com"
principal="Administrator#vecisadtest.com"
principalCredential="XXX"
useStartTLS="false"
>
<dc:FilterTemplate>
<![CDATA[
(uid=$requestContext.principalName)
]]>
</dc:FilterTemplate>
<StartTLSTrustCredential xsi:type="sec:X509Filesystem"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="UA_AD_CA_Certificate">
<sec:Certificate>C:\Progs\ShibbolethIdP\certs\VECISADTEST.pem</sec:Certificate>
</StartTLSTrustCredential>
<StartTLSAuthenticationCredential xsi:type="sec:X509Filesystem"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="IdPtoLDAPCredential">
<sec:PrivateKey>C:\Progs\ShibbolethIdP\credentials\idp.key</sec:PrivateKey>
<sec:Certificate>C:\Progs\ShibbolethIdP\credentials\idp.crt</sec:Certificate>
</StartTLSAuthenticationCredential>
</resolver:DataConnector>
login.config
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="WIN-1GB01UK5SL6.VECISADTEST.com"
port="636"
base="CN=Users,DC=vecisadtest,DC=com"
tls="false"
serviceCredential="XXX"
userRoleAttribute="sAMAccountName"
serviceUser="Administrator#vecisadtest.com"
ssl="true"
subtreeSearch = "true"
userField="sAMAccountName";
idp-metadata.xml
<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idp.janet.org:8444/idp/profile/SAML1/SOAP/AttributeQuery"/><AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.janet.org:8444/idp/profile/SAML2/SOAP/AttributeQuery"/>
Thanks.
The issue was resolved by updating the config file shibboleth2.xml on the Service Provider. The signing attribute must be set to true.
[Shibboleth Service Provider install location] \etc\shibboleth\shibboleth2.xml
SPConfig > ApplicationDefaults#signing
Default installation of Shibboleth Service Provider 2.5.2, signing attribute is false.
I did SSO of OpenAM and SalesForce.com (SFDC)
I have installed OpenAM-Client SDK to retrieve SAML Assertion from OpenAM.
I used this assertion data to generate SAML response required for SalesForce. When I pass this data to SFDC. I got error message for SAML.
“Failed: Signature Invalid/Configured Certificate Mismatch”
I used same certificate and signature data which I got from OpenAM-client SDK public API assertion.
At time of SSO configuration with SDFC. I used default certificate (test cert) provided by OpenAM.
Is there any way to retrieve test certificate and its signature from OpenAM ?
Run one of the failing SAML assertions through the SAML Validation tool inside Single Sign-On Settings in SFDC; you should get a slightly more useful error. The most likely cause of this is that you have not uploaded the correct certificate to SFDC as part of your SSO setup. Make sure the "Identity Provider Certificate" section of "Single Sign-On Settings" matches the cert contained in the assertion.