June 28-29, 2016
New York, NY
We asked you to share your giant ideas, and you listened. This year we’re excited to announce our first round of sessions.
A few topics our engineers will present on are:
- Debugging MongoDB Performance in 3.2
- Big Data with MongoDB & Spark
- Financial Transaction Management and Analysis
- Using the Cloud Manager / Ops Manager API to Scale MongoDB With Your Application
MongoDB community members and customers will share their stories, including:
- Data Analysis and Visualization with MongoDB
- Containerizing MongoDB with Kubernetes
- Creating a Single View of the Customer
- From Story to Document: Modeling Common Business Problems with MongoDB
View our list of sessions stretching across a wide range of topics list below. New talks are added every week, so keep checking back!
Need more reasons to come? At MongoDB World 2016 in New York City, you’ll experience first-hand how the world’s fastest-growing database is powering today’s innovations and can help you gain a competitive advantage. Learn how large enterprises have delivered new applications to market at the speed of a lean startup, and how startups scale and execute on their giant ideas like an enterprise.
Securing MongoDB Part 2: Database Access Control
Welcome back to our 4-part blog series presenting the best practices and controls available in MongoDB to help you create a secure, compliant database platform. In this installment, we’ll be discussing database access control – covering both authentication and authorization. In part 1, we took a look at the general requirements for data security and regulatory compliance. Looking ahead, in part 3 we’ll cover auditing and encryption. And in part 4, we’ll wrap up with environmental control and management. If you want to get a head-start and learn about all of these topics in one installment, just go ahead and download the MongoDB Security Architecture guide. Enable Access Control and Enforce Authentication The first step in securing your MongoDB database is to enable access control. As new apps and services are in development, it is typical that access control is not enforced. But once these applications are ready for test and QA, then it is important to specifically enable it, thus requiring all clients and servers provide valid credentials before they can connect to the database. This ensures that you are not deploying exposed instances when you launch your app into production. Refer to the documentation for a tutorial stepping through how to configure authentication. Ensure that MongoDB runs in a trusted network environment and limit the interfaces on which MongoDB instances listen for incoming connections. Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available. See the Security Hardening section of the documentation to learn more about reducing the risk of exposure. MongoDB Authentication The authentication of entities accessing MongoDB can be managed from within the database itself, or via integration with an external mechanism (i.e. LDAP, x.509 PKI certificates, or a Kerberos service). MongoDB Enterprise Advanced, the certified and supported production release of MongoDB is required when using LDAP or Kerberos. In Database Authentication MongoDB authenticates entities on a per-database level using the SCRAM-SHA-1 IETF standard. Users are authenticated via the authentication command, while database nodes can be authenticated to the MongoDB cluster via keyfiles. Review the authentication documentation to learn more. MongoDB Atlas Authentication MongoDB Atlas is a database as a service for MongoDB, providing all of the features of the database, without the operational heavy lifting required for any application. MongoDB Atlas has been engineered to deliver robust access controls. Authentication is enforced for all MongoDB Atlas clients via the SCRAM-SHA-1 mechanism. User and administrator roles can be defined to ensure a separation of duties between different entities accessing the database and the MongoDB Atlas service. Clients are prevented from accessing the database unless their IP address has been added to the IP whitelist for your MongoDB Atlas group. Review the MongoDB Atlas documentation for more information on configuring the in-built security controls. LDAP Authentication LDAP is widely used by many organizations to standardize and simplify the way large numbers of users are managed across internal systems and applications. In many cases, LDAP is also used as the centralized authority for user access control to ensure that internal security policies are compliant with corporate and regulatory guidelines. With LDAP integration, MongoDB can authenticate users directly against corporate LDAP infrastructure to enforce centralised access policies. Note that MongoDB currently supports LDAP authentication, and not authorization. See the following section of this post to learn more about the authorization controls available in MongoDB. Administrators can configure MongoDB to authenticate users via Linux PAM or by proxying authentication requests to a specified LDAP service. A tutorial on configuring LDAP authentication is available in documentation. Kerberos Authentication With MongoDB Enterprise Advanced, authentication using a Kerberos service is supported. Kerberos is an industry standard authentication protocol for large client/server systems, allowing both the client and server to verify each others' identity. With Kerberos support, MongoDB can take advantage of existing authentication infrastructure and processes, including Microsoft Windows Active Directory. As with LDAP and x.509 certificates, before users can authenticate to MongoDB using Kerberos, they must first be created and granted privileges within MongoDB. The process for doing this, along with a full configuration checklist is described in the MongoDB and Kerberos tutorial. x.509 Certificate Authentication With support for x.509 certificates MongoDB can be integrated with existing information security infrastructure and certificate authorities, supporting both user and inter-node authentication. Users can be authenticated to MongoDB using client certificates rather than self-maintained passwords. Inter-cluster authentication and communication between MongoDB nodes can be secured with x.509 member certificates rather than keyfiles, ensuring stricter membership controls with less administrative overhead, i.e. by eliminating the shared password used by keyfiles. x.509 certificates can be used by nodes to verify their membership of MongoDB replica sets and sharded clusters. A single Certificate Authority (CA) should issue all the x.509 certificates for the members of a sharded cluster or a replica set. Instructions for configuration are described in the MongoDB and x.509 certificates tutorial. MongoDB and Microsoft Active Directory MongoDB Enterprise Advanced provides support for authentication using Microsoft Active Directory with both Kerberos and LDAP. The Active Directory domain controller authenticates the MongoDB users and servers running in a Windows network. MongoDB Authorization MongoDB allows administrators to define the specific permissions an application or user has, and what data they can see when querying the database. User Defined Roles MongoDB provides over ten built-in roles supporting different user and administrator privileges. These can be customised through User Defined Roles, enabling administrators to assign fine-grained privileges to users or applications. Authorization privileges can be based on the specific functionality a user needs in their role, or to reflect their organizational structure. MongoDB provides the ability to specify user privileges with both database and collection-level granularity. **Figure 1**: MongoDB User Defined Roles Permit Separations of Duty Privileges are assigned to roles, and roles are in turn assigned to users. For example: Classes of users and applications can be assigned privileges to insert data, but not to update or delete data from the database DBAs may be assigned privileges that enable them to create collections and indexes on the database, while developers are restricted to CRUD operations Certain administrator roles may have cluster-wide privileges to build replica sets and configure sharding, while others are restricted to creating new users or inspecting logs Processes for monitoring MongoDB clusters can be restricted to run just those commands that retrieve server status, without having full administrative access to perform database operations Within a multi-tenant environment, “landlord” developers and administrators can be assigned permissions across physical databases, while “tenant” developers and administrators can be granted a more limited set of actions across logical databases or individual collections. This functionality enables a clear separation of duties and control, both between and within organizations. To ensure ease of account provisioning and maintenance, roles can be delegated across teams, ensuring the enforcement of consistent policies across specific functions within the organization. Review the Authorization section of the documentation to learn more about roles in MongoDB. When combined with the auditing capabilities available with MongoDB Enterprise Advanced, customers can define specific administrative actions per role, and then log all of those actions. As a result, the organization is able to enforce end-to-end operational control and maintain insight of actions for compliance and reporting. MongoDB Field Level Redaction MongoDB’s field level redaction allows building access control to individual fields of document, working in conjunction with client-side code. Implemented via the redaction stage of MongoDB’s Aggregation Pipeline, developers are provided with a method to restrict the content of a returned document on a per-field level. Permissions can be based on both the content of the document and on specific user privileges, based on security labels. Access control policies can be described using the MongoDB query language, making it simple for developers to implement the required controls. Since data is redacted before it is returned to the application, exposure of sensitive information is reduced. Field level redaction is applicable to a wide range of sensitive data including personally identifiable information such as names, social security numbers, birthdates and bank account numbers. By co-locating data with different sensitivity levels within a single document, schema and query designs are simplified. **Figure 2**: MongoDB Field Level Redaction Restricts Access to Sensitive Data The redaction logic must be passed by the application to the database on each request. It therefore relies on trusted middleware running in the application to ensure the redaction pipeline stage is appended to any query that requires the redaction logic. Getting Started with MongoDB Security With comprehensive controls for user rights management, auditing and encryption, coupled with management controls, MongoDB can meet the best practice and requirements discussed in this blog series. MongoDB Enterprise Advanced is the certified and supported production release of MongoDB, with advanced security features, including Kerberos and LDAP authentication, encryption of data at-rest, FIPS-compliance, and maintenance of audit logs. These capabilities extend MongoDB’s security framework, which includes Role-Based Access Control, PKI certificates, Field-Level Redaction, and SSL/TLS data transport encryption. In the third part of this blog post series, we will dive into MongoDB auditing and encryption. You can learn about all of these capabilities now by reading the MongoDB Security Architecture guide. If you want to try them for yourself, [download MongoDB Enterprise](https://www.mongodb.com/download-center?#enterprise), free of charge for evaluation and development. MongoDB security architecture About the Author - Mat Keep Mat is a director within the MongoDB product marketing team, responsible for building the vision, positioning and content for MongoDB’s products and services, including the analysis of market trends and customer requirements. Prior to MongoDB, Mat was director of product management at Oracle Corp. with responsibility for the MySQL database in web, telecoms, cloud and big data workloads. This followed a series of sales, business development and analyst / programmer positions with both technology vendors and end-user companies.
Leaf in the Wild: India’s Largest Publisher Unlocks Behavioral Insight with MongoDB-Powered Real Time Web Analytics Engine
Leaf in the Wild posts highlight real world MongoDB deployments. Read other stories about how companies are using MongoDB for their mission-critical projects. Times Internet Limited, the largest news publisher in India, relies on MongoDB to power its editorial analytics engine, serving more than 150 million readers with customized content and experiences. I had the chance to meet with Gagan Bajpai and Gyan Mittal, Senior Managers, Central Technical Team at Times Internet Limited (TIL) to learn more about how they use MongoDB. “We don’t ask, ‘Why MongoDB?’ anymore. Now we ask, “Why would we use anything else?’” Gyan Mittal, Senior Manager Central Technical Team, Times Internet Limited. Please start by telling us a little bit about Times Internet. Times of India Group is India's largest media and entertainment company. All of its digital platforms are run by TIL. Our websites are among the fastest growing Web and Mobile properties worldwide. Since its inception in 1999 Times Internet has led the Internet revolution in India, emerging as India's foremost web entity, and now running diverse portals and specialized websites. TIL properties reach over 150M visitors and serve 2 billion page views every month across web and mobile channels. We have brands across news, entertainment, sports, e-commerce, classifieds, startup investments, local partnerships, and more. Today, we have a diversified set of 22+ digital consumer-facing businesses. Tell us how you use MongoDB. We use MongoDB for a range of applications. This includes the content management system journalists use to upload stories, e-commerce gateways, newsletter and alerts apps, and the social platform that covers all of our web properties. We are also using MongoDB Cloud Manager for on-demand scaling and automated backups for disaster recovery. Our web analytics engine is the most critical and highest-profile application running on MongoDB. It was the first MongoDB project in TIL, and we launched it to the business in late 2010. Our editorial staff and product managers rely on the analytics engine to deepen engagement with our 150M+ audience. The engine tracks and analyses user engagement with every published story, providing feedback on how content is consumed through heat-maps and analytics dashboards. Site editors gain insights into the length of time spent per page, how content is shared across social networks, and where readers focus their attention. The analytics generated by MongoDB enable editorial staff to make data-driven decisions, improving future content to better address reader preferences, including tweaking headlines, moving copy, A/B testing of alternative images, and altering page layouts. TIL’s engine also provides personalized content recommendations based on reader’s browsing habits. Collectively, these capabilities ensure the sites’ articles are reaching and engaging with the broadest possible audience. Did you consider other databases for your app? What made you select MongoDB? My team at TIL all come from a relational database background and have massive respect for that technology. But our web analytics application presented us with a classic “big data” problem: We had to deal with large volumes of data generated by monitoring user activity tracking how content is consumed on our site. This data was coming in at high velocity from millions of concurrent users. We capture many different attributes of user behavior, so our database and analytics engine needs to handle wide variety of data structures. In addition, development agility was critical. To put this into context, Internet growth in India is much faster than pretty much anywhere else in the world. We have a huge population who are now getting access to the Internet via low-cost mobile platforms. So competition is intense, and time to market is critical. We also knew that our application would need to continually evolve to keep pace with features the business would ask us to add. So a flexible and dynamic schema was also critical to give us the agility we needed. Working with a data model that eliminates the traditional object-relational impedance mismatch would allow our developers to move with much higher velocity in building the app. Because of all of these factors, we felt a non-relational database would be a better fit for the web analytics app. That said, what we love about relational databases is the ability to run deep and complex queries against the data. And this is also where MongoDB excels. Unlike NoSQL databases that require you to integrate a search engine or replicate data to dedicated analytics nodes or Hadoop, MongoDB enables us to run rich queries against in-place data, all in real time. MongoDB’s aggregation pipeline powers our heat maps and dashboards. It is much more performant and easier to use than MapReduce. The MongoDB query language and secondary indexes give us a much more powerful framework to access and analyze multi-structured data than anything simple key-value stores can provide. Developer velocity. That’s what I am focused on. How fast can we get this robust application live in the shortest amount of time? Our team built the analytics engine in a fraction of the time it would have taken on any other database and then it scaled beautifully to help us understand and engage with millions of readers. Please describe your MongoDB deployment. Our total MongoDB estate is around 50 nodes, powering multiple apps. Most apps are powered by a single replica set configured with two data nodes and an arbiter. This provides the ideal balance between high availability and operational efficiency. Our web analytics platform is deployed on a sharded cluster. This gives us the scalability we need. We have around 1.5TB of active data in the cluster. The application itself is written in Java. We run MongoDB on Linux-based servers hosted by Rackspace in a co-location facility. Do you use any commercial services to support your MongoDB deployment? We use MongoDB Professional to back the web analytics platform. Break/fix support is important, but as our deployment and our team grows, it’s good to be able to get regular check-ins with MongoDB engineers, and review things like schema design and best practices for operational processes. As our deployment has grown, we are also now starting to evaluate the MongoDB Cloud Manager. Automated configuration and deployment can simplify on-demand scaling and upgrades, and the backup service enhanced our disaster recovery capability. What has been the business outcome of using MongoDB for your web analytic engine? We have demanding managers and editors looking to understand quickly how our readers are engaging with the news. MongoDB is the solution that helps us turn heavy raw data into actionable insights that fundamentally change the way we deliver content. Do you have plans to use MongoDB for other applications? We don’t ask, ‘Why MongoDB?’ anymore. Now we ask, ‘Why would we use anything else?’. What advice would you give someone who is considering using MongoDB for their next project? Don’t just follow the crowd. Don’t just choose the same technology you have always chosen. There is so much innovation happening today, and the databases of the last decade are not always the right choice. Once you have a short list of potential technologies, test them with your app, your queries, and your data. It is the only way to be sure you are choosing the right technology going forward. Gyan and Gagan, thank you both for your time, and sharing your experiences with the MongoDB community. Are you building big data applications? Read Big Data Examples and Guidelines to get started. Read the Big Data Examples and Guidelines About the Author - Mat Keep Mat is a director within the MongoDB product marketing team, responsible for building the vision, positioning and content for MongoDB’s products and services, including the analysis of market trends and customer requirements. Prior to MongoDB, Mat was director of product management at Oracle Corp. with responsibility for the MySQL database in web, telecoms, cloud and big data workloads. This followed a series of sales, business development and analyst / programmer positions with both technology vendors and end-user companies.