GIANT Stories at MongoDB

Identity management application using Blockchain, MongoDB Stitch & MongoDB Atlas - Part 2

Pavel Duchovny

In part 1, we got started by introducing an application where digital identity is stored in a blockchain, focusing on the use case and the proposed system architecture. In this part, we will cover the implementation details and key takeaways.

Implementation

Modern and distributed applications require a modern and distributed data platform for streamlined development and rapid scale as the network grows. Storing the data locally is not reliable, performant or scalable enough, and here is where the advantages of the MongoDB Atlas cloud database and the MongoDB Stitch serverless platform really shine, providing the best foundation to build apps with a global reach.

MongoDB Stitch

MongoDB Stitch, MongoDB’s serverless platform, allowed us to utilize several major capabilities to improve our development speed, security, and scale. Here’s how:

  • Authentication models: Various authentication and user management features allow us to easily authenticate decentralized nodes in the blockchain network (using anonymous authentication). On the other hand, consumers of the network would authenticate with advanced security mechanisms to secure their data access. For simplicity our example uses email/password authentication:
            
    async function handleLogin() {
      const email = loginEmailEl.value;
      const password = loginPasswordEl.value;
      const credential = new UserPasswordCredential(email, password);
      
      try {
      
        await stitchClient.auth.loginWithCredential(credential);
        const user = stitchClient.auth.user;
        showLoggedInState();
        displaySuccess(`Logged in as: ${user.profile.data.email}`)
    
      } catch(e) {
        handleError(e)
      }
    }
            
        
  • Stitch Rules: Flexible and easy to define authorization rules that can be applied on collection, field, and document levels give us the ability to manage data access in very sophisticated and controlled ways. One of the most fascinating abilities is to automatically project fields such as “credit_score” and “assets_range” only if a user has permissions to view them. Stitch roles allow you to filter data based on a user’s preferences:
            
    "assets_range": {
                        "read": {
                            "%or": [
                                {
                                    "%%root.owner_id": "%%user.id"
                                },
                                {                  "%%root.identity_verification_log.transaction_details.assets_shared": "assets_range"
                                }
                            ]
                        }
                    }
            
        
  • Stitch Functions: Implement hosted, server-side logic that can govern process accuracy and validate data used within the data access rules. For example, approvedByMajority verification will return true when the block actually has a majority of votes from participating blockchain nodes:
            
    function(block){
      // Get collections 
      var nodes = context.services.get("mongodb-atlas").db("assets").collection("nodes");
      var pending_blocks = context.services.get("mongodb-atlas").db("transactions").collection("pending_blocks");
      
      // Retrieve the current block
      var doc = pending_blocks.findOne({index : block.index});
      if (doc)
      {
        // Retrieve approvals vs active nodes
        currentApprovals = doc.approvals;
        
        var numberOfActiveNodes = nodes.count( {"active" : true});
        var approvedNodes = nodes.count({"owner_id" : {"$in" : currentApprovals}});
        
        // See if majority has approved
        if (approvedNodes > (numberOfActiveNodes / 2))
        {
          return true;
        }
        else
        {
          return false;
        }
        
      }
      return false;
    };
            
        
  • Stitch Triggers & third-party services: Once a user’s identity has been validated, Stitch Triggers we notify parties about offers and promotions based on the data in the blockchain.

    With third-party service integrations, we can integrate information and security gathering services easily into the process.

Trigger pushOffer.

MongoDB Atlas

Note: The Atlas cluster must be of version 3.6 and above.

MongoDB Stitch is backed with an Atlas cluster which provides us with 4 key abilities:

  • Atlas provides data access and management with scalability, resilience, and worldwide distribution to conform with privacy regulations such as GDPR and HIPAA.
  • Rich query and analytical language with a built-in Stitch hybrid connection string. In particular, we have utilized MongoDB views built on top of the $graphLookup aggregation stage, which is a key capability to traverse and validate data structures such as Blockchains.
            
    db.createView("blockchain","pending_blocks",
                [    {
                        "$match" : {
                            "index" : 0
                        }
                    },
                    {
                        "$graphLookup" : {
                            "from" : "pending_blocks",
                            "startWith" : "$previousHash",
                            "connectFromField" : "hash",
                            "connectToField" : "previousHash",
                            "as" : "chain"
                        }
                    },
                    {
                        "$unwind" : "$chain"
                    },
                    {
                        "$sort" : {
                            "chain.index" : 1
                        }
                    },
                    {
                        "$group" : {
                            "_id" : "$_id",
                            "chain" : {
                                "$push" : "$chain"
                            }
                        }
                    },
                    {
                        "$project" : {
                            "chain" : 1,
                            "_id" : 0
                        }
                    }
                ]);
    
    db.pending_blocks.createIndex({index : 1},{unique : true});
    
            
        
  • Change Streams features are a tremendous game changer for event-driven applications. Any data changing events can be filtered within Atlas when only relevant notifications to the application watcher. One main use case for this is when nodes receive a notification about a new block generated by one of the network workers:
            
    // Configure change pipeline
    const pipeline = [
                   { $match: {'fullDocument.owner_id'  : {  "$ne" : client.authedId() },
                   "operationType" : "insert" } }
                 ];
            // Get collection and set a change stream
             var db = atlasConn.db('transactions');
             const changeStream = db.collection('pending_blocks').watch(pipeline);
            
        
    MongoDB Stitch Triggers make events even simpler to process.
  • Built-in TLS and enterprise security features allow us to enforce additional levels of access control, auditing, and encryption, layering upon the governance features of MongoDB Stitch and the Blockchain itself.

Conclusions & Key Takeaways

The world of blockchain in digital systems has a tremendous potential and I believe we are going to see some extremely innovative ideas that will thrive outside of the cryptocurrency space. MongoDB enables rapid innovation, developer productivity, and scale-out for applications like this one and many others – which all benefit from decentralized data control, trust and immutability.

Identity management application using Blockchain, MongoDB Stitch & MongoDB Atlas - Part 1

Pavel Duchovny

Our physical and digital identities intersect in a million ways in today's world. Sharing and gathering information with partners and third-party vendors to streamline business processes while keeping the information secure and genuine is challenging.

Last year was big for blockchain technology. Among its many use cases, blockchain unlocks opportunities to leverage its trust, distribution, and immutability to publish identity information among various entities while maintaining a clear cryptographic ledger. Sensitive information goes through a strict approval process and is encrypted to be accessed only by specific parties. Blockchain core concepts are out of scope for this blog post. If you wish to learn more about blockchains, please refer to the resources section at the end of this blog.

Use Case

As a proof of concept, we built a blockchain identity management application. We used the blockchain structure and concepts to save and publish digital identities for a fictional bank network. Using NodeJS we have built a network of nodes which are run by the various partners in the network, pushing and governing the production of blocks within the chain.

Figure 1 : Bank-side application which shows a login verification through the blockchain ( transparent to the user)
Figure 2. Identity information is published to the blockchain.
Figure 3. Nodes on the blockchain network approve the information/encryption signatures. Other approved parties can consume the information once it is approved.

The main idea is that data can be pushed to the blockchain network by Bank A (Figure 2), consumed and approved by the majority of the network, and appear as trusted information for Bank B or C (Figure 3). Whether the information is encrypted or in the clear depends on Entity A. Using this information, Banks B and C can push offers and promotions for those customers based on the blockchain network information without the need for a centralized registration authority.

Next Steps

That’s a wrap for Part 1 of this blog series. In Part 2 we’ll cover the implementation details and key takeaways.

Learn how we built a distributed identity management application on blockchain using the MongoDB Stitch serverless platform and MongoDB Atlas cloud database service for a financial services use case.

MongoDB Ops Manager 3.4 User Interface Changes

Ops Manager 3.4, released at the beginning of December, contains both new features and changes from the previous major release, 2.0. This blog post will focus on the new Ops Manager 3.4 UI. It will cover new features and highlight changes from the previous UI.

Deployment Page

Ops Manager 3.4 has a redesigned deployment page. Items that previously appeared in the inner left-hand navigation bar now appear as tabs. Joining the existing tab for Processes are tabs for Servers and Agents. Security settings also now appear under a separate Security tab. These include USERS, ROLES and AUTHORIZATION & TSL/SSL SETTINGS. The TOPOLOGY and LIST views are now accessed via buttons. Additional functions are accessible under More: Host Mappings, Version Manager, and Logs.

 Ops Manager Deployment Page 3.4
Ops Manager Deployment Page 3.4

Alerts Tab

Ops Manager 2.0 featured dedicated icons on the top of page showing the health of the agents.

Ops Manager Alerts 2.0
Ops Manager Alerts 2.0

In Ops Manager 3.4, agent health is reported via alerts. These alerts function identically to all other alerts and appear in the Alerts tab. Agent alerts are active by default.

Ops Manager Alerts 3.4
Ops Manager Alerts 3.4

Alert Management

In Ops Manager 2.0, the alert types (OPEN ALERTS, CLOSED ALERTS, ALL ACTIVITY) are selected using buttons. The alert settings page is accessed via the ellipsis button in the upper right-hand corner of the page. The settings page contains the ADD button, via which new alerts are created.

Ops Manager 2.0 Alert Management
Ops Manager 2.0 Alert Management

In Ops Manager 3.4, the alert types have become tabs. In addition to the 3 alert types, alert settings have been moved to a fourth tab, Alert Settings. The ADD button is now on the main alerts page, right above the tabs.

Ops Manager 3.4 Alert Management
Ops Manager 3.4 Alert Management

Metrics

In Ops Manager 2.0, metric chart zoom and granularity are set via buttons. "Last Ping" information is accessed via the ellipsis button.

Ops Manager Metrics 2.0
Ops Manager Metrics 2.0

In Ops Manager 3.4, zoom and granularity were changed to drop-down menus, and an additional 10-second granularity setting was added for improved resolution. The granularity drop-down also has a new "auto" setting which chooses the optimum granularity based on the display period. "Last Ping" information is now listed under More. For HW metrics, use of munin-node is no longer required. HW metrics are automatically gathered for automated deployments.

Ops Manager Metrics 3.4
Ops Manager Metrics 3.4

Documentation and Support

For Ops Manager 2.0, documentation and support were accessed via icons in the top-right corner of the page.

Ops Manager 2.0 Docs and Support

In Ops Manager 3.4, those are accessed via buttons at the bottom of the left-hand navigation bar.

Ops Manager 3.4 Docs and Supoort

Admin Page

For Ops Manager 3.4, existing functionality on the Admin page remains identical to version 2.0. This page is also the location for accessing two new features: S3 blockstore configuration for backups (under the existing Backup button) and server pool administration (under the new Server Pool button). For more details on these features, see the Ops Manager documentation.

Ops Manager 3.4 Admin Page



Learn more about MongoDB Ops Manager 3.4.

MongoDB Ops Manager 3.4

*About the Authors*

Pavel Duchovny and Eric Sommer are Technical Services Engineers in MongoDB's Tel Aviv office. You can learn more about MongoDB Technical Support at https://docs.mongodb.com/manual/support.