Our client has a public site on sitecore, and they are asking us to create their intranet site using Sitecore.
The public and the intranet site sites have different content, but there is a possibility that both of the sites share the same content author users.
What is the best practices to achieve this? using a new instance of sitecore or the same instance.
Any thoughts?
The latest project where I used Sitecore as an intranet platform definitely had a use case for being a separate instance. While it would have been ideal to share license (as #Gatogordo points out) the organization had very strict security policies concerning network connectivity between the Intranet and internal systems.
If your intranet will have any integrations to internal network systems, you should consider the organization's security policies for a situation where a DMZ server (such as a Sitecore instance serving up a public website) is able to connect to these internal systems (such as a Sharepoint instance).
If there are no concerns on that front, HTTPS + Login requirement + disabling anonymous access via Sitecore security across the entire site should be enough. At its core, an Intranet is often just a website that people view after being logged in, and there may be some content you'll want to share between the sites or even content from the media library.
One final concern is your deployment and maintenance schedule. If you are operating the same Sitecore instances for both Intranet and Internet that means you should understand that you will likely have only one VS solution for both. Deploying a fix for the internet is also potentially affecting your intranet. This isn't a bad thing, but I have seen situations where a client did not want systems impacting each other from a deployment perspective. You can mitigate some downtime issues by using load-balanced CD nodes and also ensuring you have solid regression testing in place.
I would use the same instance: it saves you money (license) and you can share the same users for content editing. They don't need new logins and can edit both sites in the same environment.
For the front, you can easily set security on your new site to enable it as intranet. Just make sure you are running in https - best practice would be to do this for both sites.
Related
I'm running a company web application in aws. This web app is behind a cognito+External Identity provider with saml for only allowing company employees to reach the app (then they log in with local credentials to the app, as it is not possible to use saml).
In this context, does it make sense to put a WAF? A potential attacker could not launch attacks if he is not authenticated.
Thanks
Farid
A potential attacker could not launch attacks if he is not authenticated.
That's a very strong assumption. Most of incidents happen using stolen credentials, bad actors (malicious users) or an application bug
As well your application is not behind the Cognito, but both need to accesible to the clients or public internet directly.
does it make sense to put a WAF?
WAF protects partly against DDoS (filtering specific IP addresses or regions) and some other attack types (sql injection,..).
Every additional component is a tradeoff decision with complexity, usability and price. If it's worth - it is a decision if the threats or incident impacts are worth the price and effort to learn and manage the waf (baseline setup provides only baseline protection, for the best results you have to put the best effort to learn and manage the waf rules)
Maybe it's not an answer you are looking for and the question is more suited for https://security.stackexchange.com/ , but it's your decision
WAF will assist you with protecting your app from various different kinds of exploits on the web. Regardless of the AWS Cognito authentication which you have described, there are many, many vulnerabilities you might still be open to, DDOS attacks being one simple example.
If your web server is publicly accessible from a network perspective (unrelated to whether someone can login or not) then it still might make sense to use WAF.
Even an authenticated users may try to run an attack.
So WAF is of use even if you're using an IdP.
I'm developing a SPA with html5 routes.
Ex: https://app.example.com/restaurants/<restaurantId>/menu etc
Basically the app creates dynamic websites for multiple restaurants, hosted at https://app.example.com/restaurants/<restaurantId>
The requirement is to allow the restaurant owners to host the site in their own domain name.
Ex: if the restaurantId of Example Pizza Shop is xxx
then www.examplepizza.com should serve the contents of https://app.example.com/restaurants/xxx along with all the sub-routes.
The project is hosted on firebase, I'm looking for ideas on how to achieve this (even if I have to use services outside firebase it's okay)
Thanks in advance.
Firebase Hosting is not well-suited to these kinds of multi-tenant use cases, and you'll find the same is true for most "platform-as-a-service" style hosting providers.
To host arbitrary custom domains, you'll need:
Dedicated IP addresses that customers can point their DNS providers to (A records).
A web server capable of dynamically changing what it serves based on the Host header of the incoming request.
An automated SSL certificate provisioning system to create certificates for each customer's custom domain.
This is generally a major undertaking and requires quite a bit of both general and specialized knowledge. I don't think Stack Overflow is going to be the right place to find a specific solution, but I hope this guides you on your journey.
If I want a multi-tenant environment where customers can create subdomains, what are the pros and cons of creating those subdomains under myexample.com if my main company domain is example.com?
I noticed that Shopify uses myshopify.com under which their create subdomains for their customers.
Coupled with the fact that this is better for security,, it certainly appears that there's a pattern and good reason why companies do this.
Here are some examples:
Shopify
Uses shopify.com for marketing and myshopify.com for subdomain.
Basecamp
Uses basecamphq.com for marketing and basecamp.com for subdomains.
Intercom Articles
Uses intercom.com for marketing and intercom.help for subdomains.
Harvest
Uses getharvest.com for marketing and harvestapp.com for subdomains.
Status.io
Uses statuspage.io for marketing and statuspagestaging.com for subdomains.
Also this article points out the issue with untrusted content (as is the case with Shopify:
Although cookie domains do help to limit the scope of your cookies, it
is still best to avoid having untrusted hosts under your domain. This
is why GitHub pages are hosted under github.io, not github.com, for
example.
I suspect the web domain name prefixed by 'my' is purly emotional rather than technical. It's in the back-end that the domains need to be different, as a resource for enforcing security. There needs to be at least a production and an internal domain. A full suite might be Dev, DevQA, UAT, production and internal domains, with a limited number of people being able to transfer code and/or data across domains.
I am planning a Sitecore deployment, I was reading a "Separating Authoring from Delivery" http://www.awareweb.com/AwareBlog/ArchConsideration.aspx.
Do I need to install and configure Sitecore in both envioronments. In that case users can access Delivery/Sitecore and Authoring/Sitecore.
How can I actually seperate two websites? I am bit confused. Please help!
Dhanuka777, as mentioned by techphoria, you'll really have to start reading up on a lot of things before you'll be able to get more direct help.
That being said, this is the basics of what you're trying to achieve:
Delivery: This is a website running the sitecore web application, but it does not allow users to login to the Sitecore editing interface. It can only serve up the content to your extranet users.
Authoring: This is a website running the sitecore web application, but it allows users to login to the Sitecore editing interface. Extranet users cannot access it. This usually means it's running on a VM or server behind a firewall.
You will also need to look at how you want deploy your databases to support these two sites.
I work for a company that develops a software product that processes bank transactions and gives the user insight into his/her spending. Our customers (usually banks) integrate the product into their online banks.
I have a question about securing the communication between the online bank, and our system. Before I ask the question, I want to give you some background.
The bank will usually install our system on a set of servers in their hosting environment.
We offer a number of ways to integrate:
Web services - In this case the bank will make calls to a set of REST services on the server, and then generate a webpage with the results (on the server side).
Iframes - In this case the bank will embed iframes in their online bank webpages. The iframes contain webpages rendered directly from our web application.
Inline widgets - In this case the bank will embed JavaScript references on their pages. When the document loads, the JavaScript widgets will render themselves, using AJAX calls. They communicate with a proxy on the bank server, which in turn communicates with our webapp.
We currently have a custom solution where we generate and sign security tokens for the users, and pass these with the requests.
But as banks have very strict security policies, they would feel better with us using a known and trusted security protocol for the communication. It is a big concern, which we want to address.
So the question is, which protocol is best suited for the integration use cases I listed above? There is a plethora of single-sign-on standards out there, and solutions like SAML, oauth, etc. I get the feeling that these solutions might be an overkill for my situation.
I want to find a solution that is simple. As the servers will run side by side in the same hosting environment, and trust each other completely, there is no need for the end user to authorize one or the other (or being redirected between, clicking buttons to give access to the app).
That is, the security protocol should not require any intervention from the end user. The end user simply logs into his/her online bank, and via secure communication has access to the data from our web server.
So...any suggestions?
Thanks a lot!
OGG
After some deliberation, we decided to use 2-legged OAuth (online bank uses consumer key and consumer secret to sign requests to our app).
OAuth signature can either be put in a request header, or request parameters. It nicely solves our problem, as the REST requests can be signed, and the IFRAME src URL-s can also be signed (all communication is over HTTPS).
For those interested, a couple of references:
This article shows using OAuth with IFRAMEs: http://developer.tradeshift.com/blog/cross-site-user-verification/
This article mentiones some security issues with OAuth, and how threats can countered: http://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation