Building a real time application USing composer

Consider a scenario: I am building the Enterprise Web application, in which some part of the data resides in Blockchain and in the normal database. It is the authorized application. .bna has two types of participant admin and normal user

Use case 1) Customer registers as "admin" on the application form. During the process, Username and password are saved in the normal database. Now the same user needs to be created in the Blockchain as Participant "admin" in parallel using the API's.What is the complete process to create it. How can we achieve it?

Use case 2) Another Customers login as "normal" user.how can we authenticate to show, normal user data instead of "admin" user data.

thanks for your question.

The main point is that your application users (stored in the 'normal' database you mention) are registered and enrolled as Composer identities (ie via the Fabric Certificate of Authority (CA), and for which certificates are issued (thereby becoming blockchain identities, as issued by the CA that Composer is using for the business network). Those Composer identities are mapped to participants (your application user participant) in the runtime business network you deployed in Hyperledger Composer. So everyday transactions from your application users, will submit transactions (eg. create asset, update asset, invoke business transaction xyz ) as the mapped participant (and the accountability is traced back to the real identity that submitted it).

Not sure how you want to achieve it but you can obviously use the REST APIs (generated from your modeled, deployed network and consumed by your application and application architecture) or, something that happens using the JS APIs immediately after a application user registration has taken place. Its up to you.

In answer to your questions

1) An example of Identity Issue (using APIs) is here

          var businessNetwork = new BusinessNetworkConnection();
          return businessNetwork.connect('admin@tutorial-network')
            .then(() => {
                return businessNetwork.issueIdentity('org.acme.biznet.Trader#Trader_001', 'usr001')
            })
            .then((result) => {
                console.log(`userID = ${result.userID}`);
                console.log(`userSecret = ${result.userSecret}`);
            })
                .catch((error) => {
                console.error(error);
            });

            var businessNetwork = new BusinessNetworkConnection();

        // Connect as the identity

        return businessNetwork.connect('usr001@tutorial-network')
        .then(() => {
          return businessNetwork.ping();
        })
        .then((result) => {
          console.log(`participant = ${result.participant ? result.participant : '<no participant found>'}`);
        })
        .catch((error) => {
          console.error(error);
        });

from the command line you can list the issued identities using

composer identity list -c admin@tutorial-network

        $class:      org.hyperledger.composer.system.Identity
          identityId:  9b49f67c262c0ae23e1e0c4a8dc61c4a12b5119df2b6a49fa2e02fa56b8818c3
          name:        usr001
          issuer:      27c582d674ddf0f230854814b7cfd04553f3d0eac55e37d915386c614a5a1de9
          certificate: 
          state:       ISSUED
          participant: resource:org.acme.biznet.Trader#Trader_001

Obviously you can go on to create business cards (one time process) for those participants (to be able to submit transactions on the business network ) so that they can be securely shared with those application users, who (from their application) will transact on the blockchain (eg, as authenticated/registered application users to interact with the business network, say using the REST APIs).

I'm not entirely sure how your 'application admin' users would translate but it is an application admin that you would model as a Participant type in your business network in Composer. Its really about why you want to differentiate your participants on the business network, and what customer users (whether through your application or other means) should see when they access that blockchain ledger data - eg. a history of transactions they performed. A particular customer Admin may be able to see a history of transactions for that customer by application user ?

2) Is authentication the right word? The user has logged in at this stage. Perhaps you mean access control (authorization). The simplest way is that 'normal' users (participant type) and 'admin' users (as you've defined admin) is to use ACL rules for the business network, that means the Customer can only see data relevant to them and (if necessary) the type of participant user you want to control access for. But that's only for the data on the blockchain - you obviously would use a suitable authorization strategy for your normal database.