I have a CQ Dispatcher configured behind a SSO(single sign on), so when I access the dispatcher URL it will first redirect me to the SSO login page and then after entering the credentials it moves to the dispatcher(My home page).
There isn't a problem in accessing the dispatcher URL
Problem Statement
Problem is with flushing the old content in the cache and getting in the new content onto the cache.
Editing the flush agent
Under the transport tab in the URI section when I give in the value dispatcherURL/dispatcher/invalidate.cache and test the connection it says site moved to the particular sso login page.
What I did
I tried giving in the SSO credentials under the transport tab with
URI as dispatcherURL/dispatcher/invalidate.cache
I tried giving in the SSO credentials under the transport tab with
URI as
SSOURL/dispatcher/invalidate.cache [It is redirected URL]
Please share your knowledge around this.
I think the best option here is to create a new virtualhost in Apache, available without SSO. It should be configured in such manner that only flush agent (and no external clients) can access it. If Apache is installed on the same host as CQ, the virtualhost can be bound to the localhost interface. Otherwise, it should only allow connections from the CQ5 host.
The virtualhost should include the dispatcher configuration, copied from your regular virtualhost.
If you have virtualhost like this, you can configure the flush agent without need to deal with authorization.
Related
We are using Okta Customer Identity with our application. The challenge with our architecture is that each user gets their own server and subdomain, which is a little weird for Okta, because each redirect URL needs to be provided as part of the application configuration. As we add new users, the list of redirect URLs continues to grow, one per user machine. Their API is not really designed for this, so we have to write the complete list of redirect URLs with every change.
We would like to find a way to use a proxy for the Okta authentication, so that we can just have a single redirect URL for the Okta application configuration. But we're using https://github.com/okta/okta-spring-boot, and we're not really sure how to make it work with a proxy.
If we set up an HTTP proxy using -Dhttp.proxyHost=my.proxy.host -Dhttp.proxyPort=8080, that's going to affect all HTTP traffic, which is not acceptable.
Is there a way we can use an HTTP proxy purely for the Okta auth only, leaving all other HTTP traffic unproxied?
Is there something we can do with the Okta Spring Boot library that would make it possible for all user machines to share a common proxy machine?
The final alternative would be to write some "active" proxy code that runs on the proxy which handles the requests and forwards them on to Okta. It would have to introspect the Okta response and pass it back to the right user machine.
Is there a way to do #1?
Failing that, is there a way to do #2?
If neither of those are possible, are you aware of an existing implementation of #3?
I have searched only for many hours trying to find an answer but cannot. I have an up to date version of Shibboleth working in my RedHat el6.x86_64 proxy server. (SELinux is in permissive mode.) I have a Service Provider setup.
It works well with a particular default IdP. However, when I add the Embedded Discovery Service so that users can select one of two IdP's then there is a problem I cannot get passed:
The user types the resource and gets redirected to the discovery page. They select the IdP they want. They log into that IdP without a problem. After submitting their authentication to the IdP, the user gets redirected to the correct resource but THEN ALWAYS GETS IMMEDIATELY redirected back to the discovery page. In the Apache logs I see that the authentication credentials from the IdP were good.
I've looked extremely closely at the Apache configuration and do not have the redirect in there. All I have is this below for my resource as well as the default /etc/httpd/conf.d/shibboleth-ds.conf and /etc/httpd/conf.d/shib.conf files.
Order allow,deny
Allow from all
AuthType Shibboleth
require valid-user
ShibUseHeaders On
Require shibboleth
In my shibboleth2.xml file I definitely did exactly as the Shibboleth Embedded Discovery Service instructions say. Every tag is in place. I also tried different parameters within the shibboleth-ds/idpselect_config.js but that didn't help. Can someone please give me some guidance? Thank you.
The checkIP and consistentIP settings needed to be adjusted.
I have a domain example.com in AWS and have got one load balancer and one ec2 instance. Trying to setup https with certificate from AWS.
Route53 setup and A record setup is done as follows for domain to load balancer.
domain name - *.example.com
Name:-
example.com.
Type:-
- Ip4
Alias Target :- dns name of load balancer.
My web is a spring based web and it redirect user to landing page if user access www.example.com --->>> www.example.com/landing.
After all the setup, if i access like the below url, it is working fine.
https://www.example.com/landing
But if i access without www,
https://example.com/landing --> It leads to browser security page.(Your connection is not private
Attackers might be trying to steal your information from ...)
Our certificate is based on the domain name *.example.com.
If I simply access, https://example.com/ ---> It gets redirected to http://example.com/landing -- > Spring app redirects like this with http.
http://www.test.com/landing leads to certificate trust error. (https://example.com/landing).
Getting site can not be reached error if i simply access, http://www.example.com/
I am looking for URL redirection to https if user access using http or without www or without any scheme. Not sure if i have to configure anything in Route53.
Also, Do i need to configure in my app to redirect to https?
Your current certificate should not work for the root, i.e. https://test.com
Either purchase an alternate name for https://test.com or use only www.test.com as your website. You do not need to change anything in Route53 for now. You probably do need to add redirection in your webserver/app to use HTTPS-only, unless you want to leave it to the users.
I have configured Local STS with my web application (which is hosted in IIS 7 and has the host name as www.abc.com) and it can receive the claims from the STS and it can login. Now I have added another host name (www.xyz.com) to my web application. If user a login to a page in the application using www.abc.com/page1 and it redirects to local STS and it authenticates the user and adds the security token. Now if the user visits www.xyz.com/page2 it also redirects to the STS for authentication.
If a user either logged in www.abc.com or www.xyz.com they need to access the other domain page with out login. Is it possible? How do we achieve this?
In broad strokes, if you have two different relying parties, each needs to route the user to the IDP. If the IDP is configured for single sign on, the user will only notice the routing to the IDP the first time. On the second routing, (assuming same browser session and that the routing is within the lifetime supported by the IDP) the user will be authenticated without seeing a page at the IDP and being required to present credentials.
So, part of your answer hinges around what you mean by login: if you mean "experience a challenge and enter credentials" by log in, you should be able to enable this by simply ensuring that the IDP is configured for single sign on.
On the other hand, if by login you mean the redirect to the IDP, then you need to make sure the application is able to share state across the different page names. Note that usual management of state is via cookies, and note that a cookie for abc.com will not be returned to a web page named xyz.com. There are a number of clever ways to resolve this, although i am not aware of any simple application configuration solutions. One example is to have some part of both the abc.com page and the xyz.com page accessed by the url shared.com. State cookies can then be set by the shared.com transaction when logging into abc.com and read by the shared.com transaction when subsequently accessing xyz.com.
I've never had to implement such a cross domain cookie solution and have only had off-hand conversations with colleagues about it: we've always found the silent redirect of single sign on to meet our requirements. Careful research into the privacy impact of such a solution and the likelihood that such cookies might be blocked should be considered before development.
I am facing a peculiar problem. The problem is, my webapp is being installed behind a proxy. The request gets submitted to the proxy which forwards the request to the original host that is running the websphere web application.
The problem I am facing is, when I access the webapp, its URL looks like the below
http://www.myproxy.com
Lets say I get a form on this URL, when I submit the form, it is getting submitted to another URL - http://10.1.2.87
Since the URL is changing, application server thinks it is a different session and throws the login page again. The login page comes thru a filter which checks whether user is already authenticated in the session or not.
I do not have much knowledge on proxy settings .. where do you think is the problem?
Thus, you're using a reverse proxy. You need to configure it to manage the sessions as well. To the point, it should send the HTTP Cookie and Set-Cookie headers forth and back as well. Consult the documentation of the proxy in question for details or ask at serverfault.com for detailed assistance (don't forget to mention which proxy you're using).