I think I am missing something but I do not know where the code from here
https://hyperledger.github.io/composer/latest/managing/identity-issue.html
should be used.
no problem.
They're intended for use from client applications that want to 'consume' the business network (ie already deployed), ie for creating business network cards containing [issued] blockchain identities (these come from a CA server under the covers when the Composer JS API 'identity issue' is invoked - the CA server issues the actual certificates and that is combined with business network metadata to create a business network card)
The Javascript APIs / programmatic examples are when using composer-client - ie issuing identities programmatically from a client application (eg Angular-based user registration module in an app etc etc).
So an example might be where once a user is registered, you can have the 'card' creation process automated, such that they can then import to their wallet and connect to the business network. See https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/test/pii.js#L134 (FileCardStore (for storing cards on disk) would replace MemoryCardStore in this example, and the ImportCardForIdentity is a function defined further up FYI and 'alice' is the 'admin' card (in this tutorial) that is creating participants / issuing identities and then creating cards / importing them.
Another useful example here in this blog posted on the community -> https://www.skcript.com/svr/how-to-build-nodejs-application-for-your-hyperledger-composer-networks/ and
This tutorial https://medium.com/#CazChurchUk/developing-multi-user-application-using-the-hyperledger-composer-rest-server-b3b88e857ccc shows how you can use the REST APIs to create your identities from a dedicated issuer REST server. And them (just as you would from a client application), authenticate as a REST client and interact in multi-user mode with the business network, using the identities that were issued in the tutorial to call queries etc.
Related
An ex-employee planned a Microservice Architecture which is being implemented now. I've few question regarding the design and I'd highly appreciate your feedbacks.
Explanation
Dematerialized UI has a matching dematerialized API.
Dematerailized API validates the user and generates token via SSO Library.
Flight API does the I/O validation & validate the request via validate request microservice
Flight API calls Booking API to get some bookings based on the UserId
Flight API calls Print Booking API to generate Messages using Generate Message Microservice
Print Booking API must call Data Access API to get data and then call Generate PDF microservices.
Data Access API calls the database for data.
My Project Structure
FlightBookingsMicroserice.V1 //solution
ApiGatways //folder
DMZ.API/DMZ.API.csproj //Folder/project
BuildingBlocks
EventBus/EventBus.csproj
EventBus/EventBusRabbitMQ
Services
SSO
SSO.API/SSO.csproj
SSO.UnitTests
Flight
Flight.API/Flight.API.csproj
Flight.UnitTets
//Similar for all
ValidationRequest
Booking
PrintBooking
PrintBooking.API.csproj
DataAccess
DataAccess.API.csproj
GeneratePDF
GenerateMessage
UI
UI
Docker-compose
Questions
Should I be using ocelot in DMZ.API.csproj, Flight API and Print Booking API.
Is my project structure a Microservice way of development
Should I continue to use ASP.NET Core Web API with .NET 6 for Dematerialized API in orange, Function API in blue and Microservice in purple projects.
For validation, since the SSO is passed from Dematerialized UI what if the token expires while CRUD operations
is already performed for some stages [rolling back changes is a hassle].
Should each API access to an identidy server and validate the user passed and generate its own token for its
services in purple.
Thank you in advance.
The core question is if you really need all those services and if you perhaps are making things too complicated. I think the important thing is to really consider and really make sure you justify why you want to go through this route.
If you do synchronous API calls between the services, that creates coupling and in the long run a distributed monolith.
For question #4, you typically use one access token for the user to access the public service, and then you use a different set of internal tokens (machine-to-machine also called client credentials in OpenID Connect parlor) between services that have a totally different lifetime.
q1: ocelot is an API GATEWAY which is the entry point for your requests. so it should be the first layer/service meet by user request in front of your services and it forwards the request to the service according to its configuration. so it is lay in the front for all services you have. some arch provide another api gateway for different reasons like specific api gateway for mobiles request for example.
q2: as looking separate services (i cant understand function api but i assume they are services also ) yes but the microservices development is not just about separating things, its about design and identifying the services from business context (Domain Driven Design).its very challenging to identify services and their size and the way they are communicate to each other (asynchronous communication and synchronous communication).
q3: microservices is not about languages and frameworks.one of benefits of microservices architecture is its not language or framework dependent. the may be multiple languages used in microservices. choosing languages it depends on organization policy or your own reasons. if you are .net developer then go for .net.
q4: all the services are registered with identity server and they validate the given token by it. the identity server generate token (there may be multiple tokens) with scopes . the request from identified users always has the token in the headers and the services validate incoming token by referring identity server. this tokens has lifetime and also identity server generates refresh tokens in case of expiry of current token. please look at Oauth docs and rfc. also this https://www.youtube.com/watch?v=Fhfvbl_KbWo&list=PLOeFnOV9YBa7dnrjpOG6lMpcyd7Wn7E8V may helped. you can skip the basic topics. i learned a lot from this series.
I recently switched to a new company where my manager wants me to develop entirely new cloud based project in MVC. I have never worked on a project from the start and I think this is a good opportunity for me to lead.
However, I think the requirements of the clients are bit confusing.
Here is what he wants:
Client should be able to access the cloud hosted application from his network with single sign on. He wants to use his active directory for that.
There are different users in active directory, they will have different roles (I think we can handle this on database side. Create different roles and assign roles to users).
Client has to add vendor info in the application. But for this, system should send an email to vendor with the url of the cloud application. He wants user to login to the application using 2 Factor Authentication. So, send dummy password with url, and send OTP to his mobile number. Just like registering to any system.
Now my questions are:
Is it possible to have 2 different types of login mechanisms in the same application? SSO for client and 2FA for outside vendors?
If yes, could you please guide me in the right direction?
what things I need? Which framework, design pattern should I prefer?
How do I proceed ?
I'm at the stage of my project where I've
Developed the Chaincode (Model,Script,ACL,Queries)
Deployed on IBM Cloud
Developed Front-end Apps to communicate with the cloud based REST Server
Tested the code and business logic through Playground and single user REST server
Now I have to add identities, connection-profiles, & business network cards to the mix to make a production-testing ready prototype and to run REST Server on Multi-User Mode. But I'm having trouble with the said things as I can't figure out where and how to implement them. I have gone through the docs and I know that a business network card contains identity, connection-profile, and some metadata, but how exactly does the whole thing work is still confusing me.
In addition to this, is there anything else that needs to be taken care of or added to the solution to make it production-testing ready?
suggest to read the resources (URLs) provided here firstly to get some insights -> https://github.com/hyperledger/composer-knowledge-wiki/blob/latest/knowledge.md#information_source--node-js-application-development-questions-eg-build-real-time-apps-login-etc
secondly, there are some Composer sample applications you can take a look at to understand some of the issues you're asking about (and obviously - try them out!) -> https://github.com/hyperledger/composer-sample-applications/tree/master/packages eg Letter of Credit.
Finally, another example you can check out this example use case (Loyalty program, including member registration etc (eg user registration etc etc)) is here -> https://github.com/IBM/customer-loyalty-program/blob/master/web-app/app.js and the 'util' elements such as Identity registration etc https://github.com/IBM/customer-loyalty-program/blob/master/web-app/network/network.js
I developped my blockchain with composer 0.14 without problem. I managed my users (participant) with secrets and everythings was stored in the blockchain.
Now with Composer 0.15, we have to use cards to connect to the blockchain (even if a hidden function exists). I want to respect the current philosophy...
If I well understood, now I have to manage users in my webapp and make a relation between my users and theirs cards for connection to the blockchain to the right particpant. Am I right?
And other question, how to deal with multiple webapp using same particpants, do I have to generate cards on each servers?
Finally, how to make access more secure for cards saved on a server? Because, user cards can be used without theirs assent (hacking, bug, ...)
Web server : Ubuntu/NodeJS - the question can be asked for all plateforms
now I have to manage users in my webapp and make a relation between my users and theirs cards for connection to the blockchain to the right particpant. Am I right?
its more accurate to say - map your identity to the right participant in Composer.
multiple webapp
if you're spinning up separate web apps, they can use the same business network and the identities they authenticate with are mapped to participants in Composer. If an identity (mapped to a participant) uses one of those webapps then it can (say) transact on the business network in question. You could for example set up a persistent shared store accessible by your webapps or deploy a REST server with a persistent store for cards -> https://hyperledger.github.io/composer/integrating/deploying-the-rest-server.html
secure storage of cards
Hardware Security Module (cryptographic hardware-based option for key storage)? Trusted Platform Module ?
I'm now reading some introduction materials about OAuth, having the idea to use it in a free software.
And I read this:
The consumer secret must never be
revealed to anyone. DO NOT include it
in any requests, show it in any code
samples (including open source) or in
any way reveal it.
If I am writing a free client for a specific website using OAuth, then I have to include the consumer secret in the source code, otherwise making from source would make the software unusable. However, as it is said, the secret should not be release along with the source.
I completely understand the security considerations, but, how can I solve this dilemma, and use OAuth in free software?
I thought of using an external website as a proxy for authentication, but this is very much complicated. Do you have better ideas?
Edit:
Some clients like Gwibber also use OAuth, but I haven't checked its code.
I'm not sure I get the problem, can't you develop the code as open source retrieve the customer secret from a configuration file or maybe leave it in a special table in the database? That way the code will not contain the customer secret (and as such will be "shareable" as open source), but the customer secret will still be accessible to the application.
Maybe having some more details on the intended platform would help, as in some (I'm thinking tomcat right now) parameters such as this one can be included in server configuration files.
If it's PHP, I know a case of an open source project (Moodle), that keeps a php (config.php) file containing definitions of all important configurations, and references this file from all pages to get the definition. It is the responsibility of the administrator to complete the contents of this file with the values particular to that installation. In fact, if the application sees that the file is missing (usually on the first access to the site) it will redirect to a wizard where the administrator can fill the contents in a more user friendly way. In this case the customer secret will be one of these configurations, and as such will be present in the "production" code, but not in the "distributable" form of the code.
I personally like the idea of storing that value in the database in a table designed for it and possibly other parameters as the code needs not be changed. Maybe a installation wizard can be presented here ass well in the case the values do not exist.
Does this solve your problem?
If your service provider is a webapp, your server needs consumer signup pages that provides the consumer secret as the user signs up their consumer. This is the same process Twitter applications go through. Try signing up there and look at their workflow, you'll have all the steps.
If your software is peer-to-peer, each application needs to be both a service provider and a consumer. The Jira and Confluence use cases below outline that instance.
In one of my comments, I mention https://twitter.com/apps/new as the location of where Twitter app developers generate a consumer secret. How you would make such a page depends on the system architecture. If all the consumers will be talking to one server, that one server will have to have a page like https://twitter.com/apps/new. If there are multiple servers (i.e. federations of clients), each federation will need one server with this page.
Another example to consider is how Atlassian apps use OAuth. They are peer-to-peer. Setting up Jira and Confluence to talk to one another still has a setup page in each app, but it is nowhere near as complex as https://twitter.com/apps/new. Both apps are consumers and service providers at the same time. Visiting the setup in each app allows that app to be set up as a service provider with a one-way trust on the other app, as consumer. To make a two-way trust, the user must visit both app's service provider setup page and tell it the URL of the other app.