Out corporate network is set up with different Active Directory / LDAP servers, one server per each location.
Example:
Germany: ldap://ldapserver1.germany.corp.domain/DC=germany,DC=corp,DC=domain
Amerika: ldap://ldapserver2.america.corp.domain/DC=america,DC=corp,DC=domain
As I only can find american users in the american LDAP server (to authenticate), we have to configure multiple servers with multiple DC's.
Is it possible to configure such a setup with Spring Security LDAP?
Related
I have a debian based home-server running in my home network (port-forwarding is disabled due to security reasons). There are multiple services/web-applications running using docker based deployment. Is it possible to map different ports to subdomains for a hostname running in a home network?
For instance, currently I have configured my modem to provide static IP and hostname to my server and I access services using http://host-name.local:port_number. Is it possible to setup subdomains to access different applications like http://wiki.host-name.local and http://grafana.host-name.local?
Thank you for the ideas. I have gone for a CDN provider, cloudflare.com, to act as a reverse proxy and add additional layer of security for DDoS mitigation. Of course, I have also enabled Multi-factor authentication for all my web applications before exposing them on the external network. Cheers!
Where in the configuration do you enable/disable authentication for JMX in Artemis? In the artemis.profile file I have -Dcom.sun.management.jmxremote.authenticate=false on two instances of Artemis, one on a local VM and one on a remote VM. The local one doesn't require authentication (such as from JConsole) and will fail if I give is the user/password. The remote instance requires authentication, which accepts the user/password I created when setting up Artemis.
Is there another configuration I'm missing?
ActiveMQ Artemis guards JMX calls using role based authentication that leverages Artemis's JAAS plugin support with the login.config file. This is configured via the authorisation element in the management.xml configuration file and can be used to restrict access to attributes and methods on mbeans.
I have a rails 3.2 app running on Heroku which needs to proxy requests to an external API from a static IP address. Since Heroku doesn't offer elastic IPs, and Proximo is too expensive and limiting for the number of requests I need to make, I set up a simple forward proxy on an AWS EC2 micro instance in US-East using mod proxy.
I can proxy requests from my app's local environment just fine. However, requests from heroku time out. My thinking is that, since I can proxy from my local environment, the point of failure must be the connection between Heroku and my Proxy box. I've tried the answer given here: Security settings between ec2 and heroku but it didn't work. I've even tried allowing all inbound access on port 80 (even though that's terrible for the internet).
So, my question is, what are the security settings that I should enable for my ec2 instance in order to allow Heroku to proxy through it?
Heroku dynos are all running on machines within Amazon EC2 us-east-1 data center. They do not have any restrictions/firewalls on outgoing connections.
As long as you have the proper Security Group settings to allow the connections from your dynos to your own EC2 instance, you should be good.
It sounds like you haven't correctly opened up access from within us-east-1 to your instance. Double check your security group.
Information on how to edit the correct security group:
Check what security group you are using for your instance. See value
of Security Groups column in row of your instance. It's important -
I changed rules for default group, but my instance was under
quickstart-1 group when I had similar issue.
Go to Security Groups tab, go to Inbound tab, select HTTP in Create
a new rule combo-box, leave 0.0.0.0/0 in source field and click Add
Rule, then Apply rule changes.
I have one application says "app1"(main application support login) which is deploy some different machine tomcat server and another application says "app2" which also deployed in another machine tomcat server. So, should i need to install siteminder web agent to both the machine or it is on only in "appl2"?
Depends on what kind of agent you are using- if you're using a web agent for a web server (IIS, Apache), you could just install it on that box assuming it handles requests to both app servers. If you are installing the agent for the app server, Siteminder could log the user into the app on the "app1" server, and then the app/app server token could be passed to "app2"
You can use a traditional reverse proxy (apache with mod_proxy) or SiteMinder Secure Proxy Server to handle the Web Agent work and forward traffic to the destination web/app servers.
Secure Proxy Server enables your Single Sign-On environment to have "agentless" capabilities. You will still have 1 or more SiteMinder Web Agents (depending on the number of proxies that are deployed), but the web and application servers will not need to have any agents installed. The web/app servers only need to be able to consume the HTTP Headers provided by SiteMinder.
I have a simple Grails app that I've written to authenticate against an LDAP server. To develop it, I've installed ApacheDS locally and populated it with an LDIF file. Now I want to deploy it to CloudBees. Is it possible to install an LDAP server on CloudBees?
If not, an alternative seems to be to use the Grails ldap-server plugin. However, it doesn't have any documentation on how to configure it. How do I configure this plugin to load an LDIF on startup?
Unfortunately, running LDAP in a CloudBees app container/stack won't work because in-bound routing to your application port must be over HTTP/HTTPS.
Alternative 1: host the LDAP server outside of CloudBees (like on your own EC2 server)
Alternative 2: [for the highly motivated] you might be able to get a WebSocket gateway of some kind to work, but you'd special code on the client and server side to negotiate the socket stream hand-off outside of the LDAP server and client. [Client -> WS-Client --> CloudBees --> WS-Server --> LDAP Server]
gripe: why can't all protocols support virtual hosting like HTTP? -- that would make them much more Cloud-friendly :(