Hello. 

I had a similar situation earlier this year.

The Fabric SDKs contain support for maintaining a credential wallet that holds end user's HLF credentials.

If you have an architecture similar to:

Mobile App-> REST API->HLF Peer 

Then, the REST API layer can be used to translate from a security token embedded in API requests to credentials that the blockchain network will understand (ie, PKI an X509 private public key pairs).

See [1] for an example. 

Our requirements eventually shifted to an "application" id being recorded in the blockchain. So, we just issued a "system identity" that the REST API layer's SDK used for all peer interaction. So, that ended up being much simpler.

I honestly don't like the solution where the server-side app has to maintain a credential wallet that contains all registered users HLF credentials, but that does seem cleaner than having every mobile app instance issued a set of HLF credentials and directly communicating with the blockchain network. Note, I haven't seen anyone or anything pitching that architecture, but it would probably be the only alternative.

For authentication of end users on the mobile, app I'd recommend using OpenId Connect's Authorization Code Grant with a Public Client. Use one of the numerous IdaaS (Identity as a Service) Providers available today.  If OIDC is used in this manner, you also get an OAuth2 access token that can be cached in the mobile app (and refreshed as needed) and included with API calls (authorization header) to the REST API layer. An API Gateway can be used to handle authentication, authorization, request validation, and other typical concerns of API Security. All the major cloud hosting platforms offer an API Gateway solution that would do this out-of-the-box, the previous poster mentioned Kong, Apigee is another. There are a bunch of others. 

Reference:

[1] https://github.com/hyperledger/fabric-samples/tree/release-1.4/balance-transfer

RCBJ

On Tue, Dec 3, 2019 at 6:24 PM qs meng <qsmeng@...> wrote:

hi Nicholas,

 the identity be authentocated by fabric. if the kong runs outside the fabric, its result of ID authenticate is not accepted by fabric.

  I want  to authenate the requestor in the fabric.

thank you.

best regards. 

qsmeng

-------- 原始邮件 --------
发件人： Nicholas Zanutim <nlzanutim@...>
日期： 2019年12月3日周二 晚上9:31
收件人： fabric@..., qs meng <qsmeng@...>
主 题： Re: [Hyperledger Fabric] identity authentication

You can use Kong Service manager with JWT or any other form of authentication to access the services that submit transactions to the Fabric network. In this case, the user certificate must be present with the services

Em terça-feira, 3 de dezembro de 2019 10:08:44 BRT, qs meng <qsmeng@...> escreveu:

Hi experts, 

      In the current fabric design, the client app is the use of Fabric. Running a client app is a heavy cost  for a mobilephone user. We design a payment system, where a user can sign a payment request with his/her private key, submit it to a client app and then to Fabric.  

A problem exists that how the identity of the user or requestor can be authenticated?  Can anyone give me some suggestions?

 Thank you.

 Best regards,

qsmeng

 

--

Robert C. Broeckelmann Jr | Managing Director |  IyaSec

Medium.com LinkedIn Twitter Personal Blog

m: +1 314-494-3398 (SMS or WhatsApp) | fax: +1 (866) 484-1634

email: robert@... | site: iyasec.io

mail: 19215 SE 34th St Ste 106-407 Camas WA 98607-8830