My ACS URL is being rewritten from https://foo.com/ to http://foo.com/ which is causing the below Exception.
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.AssertionConsumerServiceUrlDoesNotMatchPolicyException: MSIS3200: No AssertionConsumerService is configured on the relying party trust 'foo-shibboleth-sp' that is a prefix match of the AssertionConsumerService URL 'http://foo/Shibboleth.sso/SAML2/POST' specified by the request.
The log message reflects that the auth request was sent as http as well:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://foo/Shibboleth.sso/SAML2/POST"
Destination="https://bar/adfs/ls/"
ID="_12345ID" IssueInstant="2017-08-08T22:24:28Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"><saml:Issuerxmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">foo-shibboleth-sp</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest>
2017-08-08 22:24:28 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: message encoded, sending redirect to client
I have included my configuration below.
The SP metadata I've configured in my IDP has the correct URL with https, but is being changed to http somewhere downstream and can be seen in the Shibboleth logs for the samlp auth request.
If I switch handlerSSL to TRUE, the ACS URL in the samlp auth request shows https. However, when it's set to TRUE, anything at the path of /Shibboleth.sso/ such as /Status, or /SAML2/POST are 404ing.
I should also note that this is actually a site migration and this was all on windows in a datacenter now it's on Linux in AWS. There could be an issue with the Load Balancer where we terminate SSL, but haven't been able to debug that.
In the SP metadata that was provided to the IDP, I specify the https /SAML2/POST url. There is a bunch of config here, but I tried to highlight the relevant stuff.
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_97e389f1c212...." entityID="foo-shibboleth-sp">
...
<init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://foo/Shibboleth.sso/Login"/>
....
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://foo/Shibboleth.sso/SAML2/POST" index="10"/>
Then, in the shibboleth2.xml on my SP, I have the following application override config:
<ApplicationOverride id="lms" entityID="foo-shibboleth-sp"
homeURL="/path/to/sso/location">
<Sessions lifetime="28800" timeout="3600" checkAddress="false"
handlerURL="/Shibboleth.sso" handlerSSL="false"
exportLocation="https://foo/Shibboleth.sso/GetAssertion" exportACL="127.0.0.1"
idpHistory="false" idpHistoryDays="7">
<!-- Default example directs to a specific IdP's SSO service (favoring SAML 2 over Shib 1). -->
<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
relayState="cookie" entityID="http://bar/adfs/services/trust">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
</SessionInitiator>
</Sessions>
<MetadataProvider type="XML" file="/etc/shibboleth/metadata-sp.xml"/>
<!-- Map to extract attributes from SAML assertions. -->
<AttributeExtractor type="XML" validate="true" path="/etc/shibboleth/attribute-map.xml"/>
</ApplicationOverride>
Finally, the only other piece that I have determined could be causing issues, is the IDP metadata here:
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ID="_1234-..." entityID="http://bar/adfs/services/trust">
...
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://bar/adfs/ls/" index="0" isDefault="true" />
....
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://bar/adfs/ls/" />
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://bar/adfs/ls/" />
apache config also, though it seems pretty cookie-cutter
<Location />
ShibRequestSetting applicationId lms
</Location>
<Location /path/to/sso/location>
ShibRequestSetting applicationId lms
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
</Location>
The problem ended up being related to SSL Offload with the AWS Load Balancer. Because we were terminating at the ELB, we needed to set https:// on the ServerName directive in Apache config so that it would generate the https self-referential urls.
http://httpd.apache.org/docs/2.2/mod/core.html#servername
Related
we have an IIS website that is returning 400 Bad Request for a very few users. we are using Windows Authentication
After research, I found the below info in the HTTP.err log on the server
2020-06-05 06:44:05 10.213.144.138 53021 10.11.210.147 80 HTTP/1.1 GET / - 400 - RequestLength -
I set the MaxFieldLength & MaxRequestBytes to their max values as suggested here
https://learn.microsoft.com/en-us/exchange/troubleshoot/http-proxy/400-bad-request
Still the user is receiving 400 Bad request error.
The user is part of around 200 AD groups and do not want to remove any of them.
Clear your cookies and try again, and see if you can reduce the size and amount of cookies your app is using.
When you set the registry key value you make sure you consider the below points:
1) Calculate the size of the user's Kerberos token by using the formula that's described in the following Knowledge Base article:
327825 Problems with Kerberos authentication when a user belongs to many groups
2) Set the value of MaxFieldLength and MaxRequestBytes on the server to 4/3 * T, where T is the user's token size in bytes. HTTP encodes the Kerberos token by using base64 encoding.
https://support.microsoft.com/en-us/help/2020943/http-400-bad-request-request-header-too-long-response-to-http-request
Note: Make sure you restarted the machine after doing changes.
you could also try to add below code in your site web.config file:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="500000000" />
</requestFiltering>
</security>
<system.webServer>
<system.web>
<httpRuntime maxRequestLength="500000000" executionTimeout="120" />
</system.web>
</configuration>
if you still face same issue try to use the fiddler or any other tool to capture network traffic and properly analyze the request and response header.
I'm trying to secure an application using picketlink. I'm using JBoss 6.4.18.
The SSO operation works without any issues. The problem is with the SLO, basically, picketlink sends the LogoutRequest assertion to the wrong endpoint. The IdP metadata inside my war has these endpoints:
<md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://myidp.com/saml2/soap" index="0" isDefault="true"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://myidp.com/saml2/slo" ResponseLocation="https://myidp.com/saml2/slo_return"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://myidp.com/saml2/slo" ResponseLocation="https://myidp.com/saml2/slo_return"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://myidp.com/saml2/soap"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://myidp.com/saml2/rni" ResponseLocation="https://myidp.com/saml2/rni_return"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://myidp.com/saml2/rni" ResponseLocation="https://myidp.com/saml2/rni_return"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://myidp.com/saml2/soap"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://myidp.com/saml2/sso"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://myidp.com/saml2/sso"/>
<md:NameIDMappingService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://myidp.com/saml2/soap"/>
LogoutRequest assertion looks good to me, but, picketlink sends it to the /sso endpoint instead of using /slo (as indicated by the metadata). When the idp receives that LogoutRequest it doesn't even redirect the browser back to the SP application.
The assertion actually has the correct destination, but as I said, the browser sends to the /sso endpoint.
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
Destination="https://myidp.com/saml2/sso"
Is this a bug in picketlink?
I must say that I've configured it using other IdP servers where the endpoint is the same for both types of assertions, in such cases, the SLO worked perfectly.
I'd appreciate your help on this one.
Thank you.
In the end I couldn't fix this by configuration. One would expect picketlink to send the SLO assertions to the endpoint declared in the metadata file, but as I described in the question above it doesn't.
By checking the plugin code I saw that it can read a request parameter to decide what endpoint send the Logout Request assertion to.
So, when the SP requests a GLO I add another request parameter as follows:
/?GLO=true&picketlink.desired.idp="+encodedSLOEndpointURL
picketlink reads that parameter (picketlink.desired.idp) and sends the assertion to that endpoint on the IdP side.
P.S. I hope this is the last time I have to deal with such an old library like picketlink.
I need to request a JWT Token via an HTTP request in my Spring Integration application.
I've configured a plain http outbound gatway but the server replies with a 301 Moved Permanently;
It requires the client to follow a redirect (and apparently it works this way doing some tests with SOAP-UI);
How could I make the http-outbound-gateway to follow redirects?
Tried everything I could find, but nothing worked so far.
Thanks!
You need consider to configure your HTTP Outbound Gateway with a HttpComponentsClientHttpRequestFactory. This one is based on the Apache HTTP Client 4.x and its default behavior is a DefaultRedirectStrategy which does a redirect on GET and HEAD methods and when 302, 301 or 307 status is returned for the call.
If you need to redirect POST, consider to configure an underlying HttpClient with a LaxRedirectStrategy.
See more info here: Handling HttpClient Redirects
UPDATE
To configure a LaxRedirectStrategy for the HttpClient used in the HttpComponentsClientHttpRequestFactory you need something like this:
<beans:bean id="httpClientBuilder" class="org.apache.http.impl.client.HttpClients" factory-method="custom">
<beans:property name="redirectStrategy" value="#{new org.apache.http.impl.client.LaxRedirectStrategy()}"/>
</beans:bean>
<beans:bean id="clientHttpRequestFactory"
class="org.springframework.http.client.HttpComponentsClientHttpRequestFactory">
<beans:constructor-arg>
<beans:bean factory-bean="httpClientBuilder" factory-method="build"/>
</beans:constructor-arg>
</beans:bean>
It is kinda pitta to do all that stuff in XML, so consider to move your project to Java & annotation configuration.
I have set up a shibboleth service provider on a server, 40.78.18.242. When I try to access http://40.78.18.242/secure/index.html , everything works as planned. I'm redirected to my identity provider and then, once I login, I am able to access resources in my secure directory.
I'm trying to secure a node.js application with this same Shibboleth service provider setup. I have looked into the passport-saml module, and I'm running the test project # https://github.com/gbraad/passport-saml-example/ with the following changes made to the config file:
But whenever I get redirected to the login page at the IdP, the response gives me this error:
I have a feeling I'm not understanding the requirements for passport-js correctly, as this error message only had 1-2 results in google.
Am I entering an incorrect entry point or issuer? Or can you gather what those would be, given my shibboleth2.xml file?
A snippet of my shibboleth file looks like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
logger="/etc/shibboleth/syslog.logger" clockSkew="180">
<!-- The OutOfProcess section contains properties affecting the shibd daemon. -->
<OutOfProcess logger="/etc/shibboleth/shibd.logger">
<!--
<Extensions>
<Library path="odbc-store.so" fatal="true"/>
</Extensions>
-->
</OutOfProcess>
<InProcess logger="/etc/shibboleth/native.logger" />
<UnixListener address="shibd.sock" />
<!-- This set of components stores sessions and other persistent data in daemon memory. -->
<StorageService type="Memory" id="mem" cleanupInterval="900"/>
<SessionCache type="StorageService" StorageService="mem" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
<ReplayCache StorageService="mem"/>
<ArtifactMap artifactTTL="180"/>
<!-- This set of components stores sessions and other persistent data in an ODBC database. -->
<!--
<StorageService type="ODBC" id="db" cleanupInterval="900">
<ConnectionString>
DRIVER=drivername;SERVER=dbserver;UID=shibboleth;PWD=password;DATABASE=shibboleth;APP=Shibboleth
</ConnectionString>
</StorageService>
<SessionCache type="StorageService" StorageService="db" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
<ReplayCache StorageService="db"/>
<ArtifactMap StorageService="db" artifactTTL="180"/>
-->
<!-- To customize behavior, map hostnames and path components to applicationId and other settings. -->
<RequestMapper type="Native">
<RequestMap applicationId="default">
<!--
The example requires a session for documents in /secure on the containing host with http and
https on the default ports. Note that the name and port in the <Host> elements MUST match
Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element
below.
-->
<Host name="40.78.18.242"
applicationId="rename--my-application-name"
authType="shibboleth"
requireSession="true"
exportAssertion="false">
<AccessControl>
<!-- IMPORTANT: You must replace this with your application's entitlement
when switching to production! -->
<Rule require="entitlement">urn:mace:usc.edu:gds:entitlement:stmn7vt3</Rule>
</AccessControl>
</Host>
<!-- Examples of a second vhost mapped to a different applicationId. -->
<!--
<Host name="admin.example.org" applicationId="admin" authType="shibboleth" requireSession="true"/>
or
<Host name="admin.example.org">
<Path name="applicationPath" applicationId="admin" authType="shibboleth" requireSession="true" exportAssertion="false">
<AccessControl>
<Rule require="entitlement">urn:mace:usc.edu:gds:entitlement:yourentitlementvaluehere</Rule>
</AccessControl>
</Path>
</Host>
-->
</RequestMap>
</RequestMapper>
<!--
The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined.
Resource requests are mapped by the RequestMapper to an applicationId that
points into to this section.
These are the default global settings for all applications.
!DO NOT CHANGE THIS SECTION! Application-specific settings are set in the
<ApplicationOverride> section.
-->
<ApplicationDefaults id="default" policyId="default"
entityID="https://www.usc.edu/do-not-use"
homeURL="https://www.usc.edu/"
REMOTE_USER="eppn persistent-id targeted-id"
signing="true" encryption="false"
>
<!--
Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
You MUST supply an effectively unique handlerURL value for each of your applications.
The value can be a relative path, a URL with no hostname (https:///path) or a full URL.
The system can compute a relative value based on the virtual host. Using handlerSSL="true"
will force the protocol to be https. You should also add a cookieProps setting of "; path=/; secure; HttpOnly"
in that case. Note that while we default checkAddress to "false", this has a negative
impact on the security of the SP. Stealing cookies/sessions is much easier with this disabled.
-->
<Sessions lifetime="7200" timeout="3600" checkAddress="false" consistentAddress="true"
handlerURL="/Shibboleth.sso" handlerSSL="true"
exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
cookieProps="; path=/; secure; HttpOnly"
idpHistory="true" idpHistoryDays="7">
<!--
SessionInitiators handle session requests and relay them to a Discovery page,
or to an IdP if possible. Automatic session setup will use the default or first
element (or requireSessionWith can specify a specific id to use).
-->
<!-- Default example directs to a specific IdP's SSO service (favoring SAML 2 over Shib 1). -->
<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
relayState="cookie" entityID="https://shibboleth-test.usc.edu/shibboleth-idp"
acsByIndex="false">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
</SessionInitiator>
<!-- An example using an old-style WAYF, which means Shib 1 only unless an entityID is provided. -->
<SessionInitiator type="Chaining" Location="/WAYF/shibboleth.usc.edu" id="usc" relayState="cookie">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
<SessionInitiator type="WAYF" acsIndex="5" URL="https://shibboleth-test.usc.edu/idp/profile/Shibboleth/SSO"/>
</SessionInitiator>
<!--
md:AssertionConsumerService locations handle specific SSO protocol bindings,
such as SAML 2.0 POST or SAML 1.1 Artifact. The isDefault and index attributes
are used when sessions are initiated to determine how to tell the IdP where and
how to return the response.
-->
<md:AssertionConsumerService Location="/SAML2/POST" index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
<md:AssertionConsumerService Location="/SAML2/Artifact" index="3"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<md:AssertionConsumerService Location="/SAML2/ECP" index="4"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>
<md:AssertionConsumerService Location="/SAML/POST" index="5"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
<md:AssertionConsumerService Location="/SAML/Artifact" index="6"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>
<!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
<LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie" >
<!-- <LogoutInitiator type="SAML2" template="bindingTemplate.html"/> -->
<LogoutInitiator type="Local" />
</LogoutInitiator>
<!-- md:SingleLogoutService locations handle single logout (SLO) protocol messages. -->
<md:SingleLogoutService Location="/SLO/SOAP"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<!-- md:ManageNameIDService locations handle NameID management (NIM) protocol messages. -->
<md:ManageNameIDService Location="/NIM/SOAP"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<!--
md:ArtifactResolutionService locations resolve artifacts issued when using the
SAML 2.0 HTTP-Artifact binding on outgoing messages, generally uses SOAP.
-->
<md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<!-- Extension service that generates "approximate" metadata based on SP configuration. -->
<Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
<!-- Status reporting service. -->
<Handler type="Status" Location="/Status" acl="127.0.0.1"/>
<!-- Session diagnostic service. -->
<Handler type="Session" Location="/Session" showAttributeValues="true" />
</Sessions>
<!--
You should customize these pages! You can add attributes with values that can be plugged
into your templates. You can remove the access attribute to cause the module to return a
standard 403 Forbidden error code if authorization fails, and then customize that condition
using your web server.
-->
<Errors session="/etc/shibboleth/sessionError.html"
metadata="/etc/shibboleth/metadataError.html"
access="/etc/shibboleth/accessError.html"
ssl="/etc/shibboleth/sslError.html"
localLogout="/etc/shibboleth/localLogout.html"
globalLogout="/etc/shibboleth/globalLogout.html"
supportContact="peter.kaminski09#gmail.com"
logoLocation="/shibboleth-sp/logo.jpg"
styleSheet="/shibboleth-sp/main.css"/>
<MetadataProvider type="XML"
url="https://shibboleth.usc.edu/USC-metadata.xml"
backingFilePath="USC-metadata.xml"
reloadInterval="86400" />
<!-- Chain the two built-in trust engines together. -->
<TrustEngine type="Chaining">
<TrustEngine type="ExplicitKey"/>
<TrustEngine type="PKIX"/>
</TrustEngine>
<!-- Map to extract attributes from SAML assertions. -->
<AttributeExtractor type="XML" path="/etc/shibboleth/attribute-map.xml"/>
<!-- Use a SAML query if no attributes are supplied during SSO. -->
<AttributeResolver type="Query"/>
<!-- Default filtering policy for recognized attributes, lets other data pass. -->
<AttributeFilter type="XML" path="/etc/shibboleth/attribute-policy.xml"/>
<!-- Simple file-based resolver for using a single keypair. -->
<CredentialResolver type="File"
key="/etc/shibboleth/sp-key.pem"
certificate="/etc/shibboleth/sp-cert.pem"/>
<!-- *************************************** -->
<!-- Custom application settings begin here. -->
<!-- *************************************** -->
<!--
In the ApplicationOverride section:
id - should match the name you use in the RequestMapper
Rename this value to the name of your application.
If you have multiple applications, they will have
multiple ApplicationOverride sections with different id=""
entityID - should be set for you automatically by the generator
please follow the instructions in detail from the website
regarding your entityID. This is an overall identifer
for your application and should not be linked to a
specific box, but should be a link into the space of
your overall departmental website. It does not have
to resolve to anything, but may one day be used to
house a configuration file.
homeURL - this value will vary by machine. This is where shibboleth
will return when it can do nothing further with a request.
REMOTE_USER - If you would like the standard REMOTE_USER definition
in the environment of your application, set this value.
For example, if you receive uscNetID, you would set:
REMOTE_USER="ShibuscNetID"
(That is the identifier defined in attribute-map.xml)
-->
<ApplicationOverride id="rename--my-application-name"
entityID="https://www.trojantime.usc.edu/timesheethistorial/shibboleth-sp"
homeURL="http://40.78.18.242/"
REMOTE_USER="ShibuscNetID" />
</ApplicationDefaults>
<!-- Policies that determine how to process and authenticate runtime messages. -->
<SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>
</SPConfig>
According to passport-saml docs, the default NameID Format is urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, quoting:
identifierFormat: optional name identifier format to request from identity provider (default: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress)
So your IDP is not supported the requested NameID Format. You need either to change the SP passport settings to a NameID Format IDP supports, or request to IDP admin (if you don't have direct access to it) to accept emailAddress.
I'm new in wso2 esb.
I am trying to make a secure proxy to protect a non secure web service.
I follow different tutorials and I do the following configuration for my proxy:
`<proxy xmlns="http://ws.apache.org/ns/synapse"
name="ProxyStockeSecure"
transports="https,http,local"
statistics="disable"
trace="disable"
startOnLoad="true"><target inSequence="LogAndRemoveHeader" outSequence="LogSeqResponse">
<endpoint>
<address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
</endpoint></target><publishWSDL uri="http://localhost:9000/services/SimpleStockQuoteService?wsdl"/><enableSec/><policy key="sec_policy"/><description/></proxy>
The LogAndRemoveHeader sequence removes the security Header and log the flow.
<sequence xmlns="http://ws.apache.org/ns/synapse" name="LogAndRemoveHeader"><log level="full"></log><header xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" name="wsse:Security" scope="default" action="remove"></header><log level="full"></log></sequence>
When I send a signed request to the secure proxy I can see that the proxy validates it well (thanks to rampart).
But when I look at the log on the back end server, I see that the Security header is still present while I remove it in the "LogAndRemoveHeader" sequence.
In the WSO2 server, I can see that the Security is correctly removed:
TID: [0] [ESB] [2015-03-19 01:20:31,508] INFO {org.apache.synapse.mediators.builtin.LogMediator} - To: /services/ProxyStockeSecure, WSAction: urn:getSimpleQuote, SOAPAction: urn:getSimpleQuote, MessageID: urn:uuid:7d951378-9a98-4b60-bcba-cded778ee977, Direction: request, Envelope: <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:ser="http://services.samples"><soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-1150340834">
<ser:getSimpleQuote>
<!--Optional:-->
<ser:symbol>1</ser:symbol>
</ser:getSimpleQuote></soap:Body></soap:Envelope>
But, on the back end server, the security header is back and I feel that wso2 has re-signed the request. Indeed, the DigestValue or SignatureValue differs from the original request...
Use send mediator to send your request to backend service inside your LogAndRemoveHeader sequence. Here is the sample send mediator code.
<send>
<endpoint>
<address uri="http://localhost:9000/services/SimpleStockQuoteService"></address>
</endpoint>
</send>