I have a protected page setup in AEM using the Authentication Requirement checkbox on the author. Then over in the OSGi I have config for my external Okta SAML config:
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:OsgiConfig"
identitySyncType="default"
keyStorePassword="admin"
service.ranking="5002"
idpHttpRedirect="{Boolean}false"
createUser="{Boolean}true"
defaultRedirectUrl="/"
userIDAttribute="ssoGuid"
idpIdentifier=""
assertionConsumerServiceURL=""
defaultGroups="[everyone]"
storeSAMLResponse="{Boolean}false"
signatureMethod="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
idpCertAlias="certalias___1657659258516"
addGroupMemberships="{Boolean}true"
path="[/content/mySite]"
digestMethod="http://www.w3.org/2001/04/xmlenc#sha256"
synchronizeAttributes="[...]"
clockTolerance="60"
groupMembershipAttribute="groupMembership"
idpUrl="oktaURL"
serviceProviderEntityId="https://stage.mySite.com"
logoutUrl=""
handleLogout="{Boolean}false"
userIntermediatePath="sso"
spPrivateKeyAlias=""
useEncryption="{Boolean}false"
nameIdFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
And in my okta config, I have https://stage.mySite.com/saml_login as the SSO URL and https://stage.mySite.com as the audience restriction.
When I navigate to the requested page in AEM I get redirected to Okta, I sign in and am redirected to https://stage.mySite.com/saml_login, all of this is expected, here is where it gets weird, I then get a 301 redirect to https://stage.mySite.com/saml_login.html which then gives a 404. It seems like AEM does not have a listener setup and so does the redirect.
Any thoughts on what i might have misconfigured?
In my case, it was a dispatcher config issue (or nginx, not sure where the rewrite was done).
It was setup to append '.html' if it does not exist in the requested url. I needed to make an exception for that rule.
Related
Can someone explain how workspace proxy works?
Whats the right configuration so I can make requests from shell (please see below)?
I have Geoserver running in a docker container and is listening in the host on port 12018.
Everything is fine accesing through the web browser.
The following URL request works on browser:
http://localhost:12018/geoserver/geonode/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=my_data_name35&maxFeatures=50&outputFormat=application%2Fjson
Using typeName as geonode:my_data_name35 also works:
http://localhost:12018/geoserver/geonode/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=geonode%3Amy_data_name35&maxFeatures=50&outputFormat=application%2Fjson
But from cURL, the first request returns:
<?xml version="1.0" ?>
<ServiceExceptionReport
version="1.2.0"
xmlns="http://www.opengis.net/ogc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/ogc http://schemas.opengis.net/wfs/1.0.0/OGC-exception.xsd">
<ServiceException code="InvalidParameterValue" locator="typeName">
Feature type :my_data_name35 unknown
</ServiceException></ServiceExceptionReport>
And also from cURL, the second request returns:
<?xml version="1.0" ?>
<ServiceExceptionReport
version="1.2.0"
xmlns="http://www.opengis.net/ogc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/ogc http://schemas.opengis.net/wfs/1.0.0/OGC-exception.xsd">
<ServiceException code="InvalidParameterValue" locator="typeName">
Feature type geonode:my_data_name35 unknown
</ServiceException></ServiceExceptionReport>
Any help is appreciated. Thanks!
I found the problem, very basic actually.
The resource requested needs authentication, where the browser passes the cookie.
Using cURL, also needs to pass authentication.
It does not return forbidden maybe because some resources don't need authentication.
Sorry for the noise.
AWS Elastic Load Balancer listening through HTTPS (443) using SSL and redirecting requests to EC2 instances through HTTP (80), with IIS hosting a .net webapi application, using swashbuckle to describe the API methods.
Home page of the API (https://example.com) has a link to Swagger documentation which can bee read as https://example.com/swagger/ui/index.html when you hove over on the link.
If I click on the link it redirects the request on the browser to http://example.com/swagger/ui/index.html which displays a Page Not Found error
but if I type directly in the browser URL https://example.com/swagger/ui/index.html then it loads Swagger page, but then, when expanding the methods an click on "Try it out", the Request URL starts with "http" again.
This configuration is only for Stage and Production environments. Lower environments don't use the load balancer and just use http.
Any ideas on how to stop https being redirected to http? And how make swagger to display Request URLs using https?
Thank you
EDIT:
I'm using a custom index.html file
Seems is a known issue for Swashbuckle. Quote:
"By default, the service root url is inferred from the request used to access the docs. However, there may be situations (e.g. proxy and load-balanced environments) where this does not resolve correctly. You can workaround this by providing your own code to determine the root URL."
What I did was provide the root url and/or scheme to use based on the environment
GlobalConfiguration.Configuration
.EnableSwagger(c =>
{
...
c.RootUrl(req => GetRootUrlFromAppConfig(req));
...
c.Schemes(GetEnvironmentScheme());
...
})
.EnableSwaggerUi(c =>
{
...
});
where
public static string[] GetEnvironmentScheme()
{
...
}
public static string GetRootUrlFromAppConfig(HttpRequestMessage request)
{
...
}
The way I would probably do it is having a main file, and generating during the build of your application a different swagger file based on the environnement parameters for schemes and hosts.
That way, you have to manage only one swagger file accross your environments, and you only have to manage a few extra environnement properties, host and schemes (if you don't already have them)
Since I don't know about swashbuckle, I cannot answer for sure at your first question (the redirect)
I have a question about the urlrewritefilter and until now I could not find anything about it in the net.
I want to redirect a http POST in Tomcat7. Here is an example...
The call is a HTTP POST to an ULR like
http://localhost:8080/oldApplication/Example?a=123&b=2
This call also contains some content either as xml or json. The filter is configured well as it works and the urlrewrite.xml contains:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN"
"http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
<urlrewrite use-query-string="true">
<rule>
<condition type="method">POST</condition>
<from>^(.*)$</from>
<to type="redirect">/newApplication$1</to>
</rule>
</urlrewrite>
In the access log I can see that a call to
http://localhost:8080/oldApplication/Example?a=123&b=2
gets redirected to
http://localhost:8080/newApplication/Example?a=123&b=2
Fine until now. The problem is that the rewrite changes the method, so that the new url gets called with a HTTP GET instead of a HTTP POST. I tried to add a condition on the method but got still a HTTP GET after the rewrite.
Does anybody know how to configure the rewritefilter to avoid this?
You are using the type attribute redirect on type="redirect"
This attribute is equivalent to HttpServletResponse.sendRedirect() that actually does a new request to the destination using the GET method, so all parameters are lost along with the HTTP method.
The default value for this attribute if not informed is forward that is equivalent to HttpServletRequest.getRequestDispatcher(url).forward()
Forwarding will keep all request parameters and also the HTTP method.
So, in order to obtain the desired result you have to omit your type attribute or set it to forward.
<to>/newApplication$1</to>
or
<to type="forward">/newApplication$1</to>
I use JOSSO 1.8.6. I configure all in the Tomcat lib directory file related to JOSSO, and I'm also doing all configuration in web application[spring] WEB-INF file. I got the below URL.
http://localhost:8080/TestLogin/?josso_cmd=login_optional
&josso_back_to=http://localhost:8080/TestLoginDemo/josso_security_check
&josso_partnerapp_id=TestLoginDemo
But my question is:
My parent web application is --TestLogin means this application login page is main to display all the other web application [child web application].
I have 3 child application
TestLoginDemo
jossoLogin1
JossoLoginDemo
All are spring application.
I hit in browser mean URL is http://localhost:8080/TestLoginDemo
So the below URL I see
http://localhost:8080/TestLogin/?josso_cmd=login_optional
&josso_back_to=http://localhost:8080/TestLoginDemo/josso_security_check
&josso_partnerapp_id=TestLoginDemo
But after the successful login I find the TestLogin flow means not transfer to the TestLoginDemo.
So what is the way if I have to carry on flow for TestLoginDemo?
And; after success this URL:
http://localhost:8080/TestLogin/?josso_cmd=login_optional
&josso_back_to=http://localhost:8080/TestLoginDemo/josso_security_check
&josso_partnerapp_id=TestLoginDemo
login page I got below URL in success:
http://localhost:8080/TestLogin/login.htm
instead of the below correct URL:
http://localhost:8080/TestLoginDemo/login.htm
Could anybody guide me on how to achieve this?
Why josso_cmd=login_optional, did you set it up like this ? By default this is unecessary to specify the josso_cmd argument.
In order to get back to the original application, you have to use josso_partnerapp_ctx argument (don't forget to encode URL), this will be passed to the security check page that will lead you to this page if the security check is sucessfull
Usually, URL looks like this:
https://login.domain.com/josso/signon/login.do?josso_back_to=https://site.domain.com/Josso/Check&josso_partnerapp_host=site.domain.com&josso_partnerapp_ctx=https%3a%2f%2site.domain.com%2fhome.html
First off, I'm new to portal development in general, and thus have no previously experience with Websphere Portal. Note: URLs have been changed to protect the innocent.
I have a portlet on Websphere Portal 7 where I'm trying to make an Ajax call (a POST in this case) to another server. I know I have to create the proxy-config and wire up the ProxyServlet so Portal will allow the cross site ajax call, and I have done that. However, I'm getting a 403 Forbidden message when calling the proxied service.
Here's my proxy-config.xml:
<proxy:proxy-rules
xmlns:proxy="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<proxy:mapping contextpath="/proxy" url="*"/>
<proxy:policy acf="none" url="*">
<proxy:actions>
<proxy:method>GET</proxy:method>
<proxy:method>POST</proxy:method>
</proxy:actions>
</proxy:policy>
<proxy:policy acf="none" url="https://subdomain.domain.org/ss/services/*">
<proxy:actions>
<proxy:method>GET</proxy:method>
<proxy:method>POST</proxy:method>
</proxy:actions>
</proxy:policy>
<proxy:meta-data>
<proxy:name>max-connections-per-host</proxy:name>
<proxy:value>5</proxy:value>
</proxy:meta-data>
<proxy:meta-data>
<proxy:name>max-total-connections</proxy:name>
<proxy:value>100</proxy:value>
</proxy:meta-data>
</proxy:proxy-rules>
Here is the ProxyServlet in web.xml:
<servlet>
<servlet-name>ProxyServlet</servlet-name>
<servlet-class>com.ibm.wps.proxy.servlet.ProxyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>/ss/services/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>/proxy/*</url-pattern>
</servlet-mapping>
And here is the URL that I'm attempting to call from javascript (via jQuery):
"wps/proxy/https/subdomain.domain.org/ss/services/service1"
I'm currently getting 403 Forbidden "The URL you tried to access through the proxy is not allowed" error message. And this is the URL Firebug shows the portlet is hitting (seems to be correct):
http://portalsubdomain.domain.org:77777/wps/proxy/https/subdomain.domain.org/ss/services/service1.
Based on the proxy docs for wp7, I know 403 means one of the following:
The request was not accepted by the proxy, that is the proxy found no matching access policy that grants access to the target server.
Basic authentication failed.
It should've found the proxy policy since I have it defined for all URLs, so what am I missing? I'm figuring I either haven't configured the proxy policy correctly (authentication?) or I haven't constructed the URL in the JSON call correctly. I reviewed the format "rules" but haven't been able to come up with a solution that works.
A couple of things to note:
This portlet is on a child page of another page, and dojo is part of a custom theme we created
We are using LDAP to log into the portal, so not sure if that makes any difference as well. I'm logging in with portal admin rights when running this.
The URL for the page where the portlet is being loaded (and thus the page/space structure) is http://portalsubdomain.domain.org:77777/wps/demoportal/home/demo/ajaxTest. Not sure what the proxy is looking for, but the proxy-config.xml is located within my portlet's WEB-INF folder.
If I change the URL in my JSON call to wps/demoportal/home/demo/ajaxTest/proxy/https/subdomain.domain.org/ss/services/service1, I get the HTML for the ajaxTest page in return.
Found the solution! I needed to get the context path of the portlet and prepend it to the service URL.
Since my service call is in a separate .js file (via JavascriptMVC & jQuery), my quick and dirty fix is to create a JavaScript variable on the .jsp in order to get the portlet context path like so:
var globalRequestContextUrl = "<%= renderResponse.encodeURL(renderRequest.getContextPath()) %>";
then in my ajax call, I prepend the context url to my call to the proxy like so:
globalRequestContextUrl + "https/subdomain.domain.org/ss/services/service1"
Now I'm fighting SSL certificate issues, but I'm definitely getting through the proxy now.