In Hyperledger composer rest api (composer-rest-server) are secure with Enabling authentication for the REST server. but in http://localhost:3000/explorer, All sensitive data is not encryption. Could i use cryptography or other approach to encrypt and decrypt like Zero Knowledge Proof to prevent data privacy (sensitive data)?
And I see Securing the REST server using HTTPS and TLS, when i run command composer-rest-server -c alice1#my-network -t and then open browser https://localhost:3000/explorer, but I don't know how to use it?
Thank you in advance!
Firstly, you would use TLS between the REST client and REST server - see https://hyperledger.github.io/composer/latest/integrating/securing-the-rest-server and general/useful info on TLS with diagrams here
You would really need to set up authentication (known user identities that are using it) with TLS like discussed here then connect to the authentication path for your application to authenticate the user using the REST APIs https://localhost:3000/auth/github: ((or whatever the authPath is for your implemented strategy)) and then interactions/ data in transit between client and server will be encrypted.
Once the REST server is up and running and TLS enabled - you will authenticate at your REST client as the user in question: once authenticated, that user gets an access token or similar. In terms of Composer and the deployed business network / smart contract - that user will (already) have been issued a business network card - that includes the user's blockchain identity (key/cert) and contain connection info/metadata (ie how to connect to the deployed/runtime business network out on the Fabric network). This access may be programmatically, from an application client that's using REST APIs (ie the app user that's logged in to the app, has been assigned this business network card) or indeed - a user is using the REST API client in a browser for example (eg. he/she would import it into their Wallet in the REST client then that would be the default identity in the REST API session, and which interacts / signs transactions that update the business network (create asset, update asset etc), as REST API operations to the REST Server (over TLS) that interacts with the Fabric network (over TLS).
Related
I'm writing an application that uses keycloak as its user authentication service. I have normal users, who log in to keycloak from the frontend (web browsers), and service users, who log in from the backend (PHP on IIS). However, when I log in from the backend, keycloak uses HS256 as its signature algorithm for the access token, and thus rejects it for further communication because RS256 is set in the realm and client settings. To get around this issue, I would like to "pretend to be the frontend" to get RS256 signed access tokens for my service users.
For security reasons, I cannot give the HS256 key to the application server, as it's symmetrical and too many people can access the server's code.
I am currently debugging the issue using the same user/pw/client id/grant type both on the frontend and the backend, so that cannot be the issue.
So far I have tried these with no luck:
copying the user agent
copying every single HTTP header (Host, Accept, Content-Type, User-Agent, Accept-Encoding, Connection, even Content-Length is the same as the form data is the same)
double checking if the keycloak login is successful or not - it is, it's just that it uses the wrong signature algorithm
So how does keycloak determine which algorithm to sign tokens with? If it's different from version to version, where should I look in keycloak's code for the answer?
EDIT: clarification of the flow of login and reasons why backend handles it.
If a user logs in, this is what happens:
client --[login data]--> keycloak server
keycloak server --[access and refresh token with direct token granting]--> client
client --[access token]--> app server
(app server validates access token)
app server --[data]--> client
But in some occasions the fifth step's data is the list of users that exist in my realm. The problem with this is that keycloak requires one to have the view-users role to list users, which only exists in the master realm, so I cannot use the logged in user's token to retrieve it.
For this case, I created a special service user in the master realm that has the view-users role, and gets the data like this:
client --[asks for list of users]--> app server
app server --[login data of service user]--> keycloak server
keycloak server --[access token with direct granting]-->app server
app server --[access token]--> keycloak server's get user list API endpoint
(app server filters detailed user data to just a list of usernames)
app server --[list of users]--> client
This makes the the list of usernames effectively public, but all other data remains hidden from the clients - and for security/privacy reasons, I want to keep it this way, so I can't just put the service user's login data in a JS variable on the frontend.
In the latter list, step 4 is the one that fails, as step 3 returns a HS256 signed access token. In the former list, step 2 correctly returns an RS256 signed access token.
Thank you for the clarification. If I may, I will answer your question maybe differently than expected. While you focus on the token signature algorithm, I think there are either mistakes within your OAuth2 flows regarding their usage, or you are facing some misunderstanding.
The fact that both the backend and frontend use "Direct Access Granting" which refers to the OAuth2 flow Resources Owner Credentials Grant is either a false claim or is a mistake in your architecture.
As stated by Keycloak's own documentation (but also slightly differently in official OAuth.2 references):
Resource Owner Password Credentials Grant (Direct Access Grants) ... is used by REST clients that want to obtain a token on behalf of a
user. It is one HTTP POST request that contains the credentials of the
user as well as the id of the client and the client’s secret (if it is
a confidential client). The user’s credentials are sent within form
parameters. The HTTP response contains identity, access, and refresh
tokens.
As far as I can see the application(s) and use case(s) you've described do NOT need this flow.
My proposal
Instead what I'd have seen in your case for flow (1) is Authorization Code flow ...
assuming that "Client" refers to normal users in Browser (redirected to Keycloak auth. from your front app)
and assuming you do not actually need the id and access tokens back in your client, unless you have a valid reasonable reason. As the flows allowing that are considered legacy/deprecated and no more recommended. In this case, we would be speaking of Implicit Flow (and Password Grant flow is also discouraged now).
So I think that the presented exchange (first sequence with points 1 to 5 in your post) is invalid at some point.
For the second flow (backend -> list users), I'd propose two modifications:
Allow users to poll the front end application for the list of users and in turn the front-end will ask the backend to return it. The backend having a service account to a client with view-roles will be able to get the required data:
Client (logged) --> Request list.users to FRONTEND app --> Get list.users from BACKEND app
(<--> Keycloak Server)
<----------------------------------------- Return data.
Use Client Credentials Grant (flow) for Backend <> Keycloak exchanges for this use case. The app will have a service account to which you can assign specific scopes+roles. It will not work on-behalf of any user (even though you could retrieve the original requester another way!) but will do its work in a perfectly safe manner and kept simple. You can even define a specific Client for these exchanges that would be bearer-only.
After all if you go that way you don't have to worry about tokens signature or anything like that. This is handled automatically according to the scheme, flow and parties involved. I believe that by incorrectly making use of the flows you end up having to deal with tricky token issues. According to me that is the root cause and it will be more helpful than focusing on the signature problem. What do you think?
Did I miss something or am I completely wrong...?
You tell me.
I have created an MVC Web application application and a storage account(Table). I'm getting the error
StatusMessage:The account being accessed does not support http.
ErrorCode:AccountRequiresHttps
When I created an MVC application, I have ticked Configure for Https. Would anyone know where I can configure it to use https and why I'm not able to access it? (I tried running on both IIS express and IIS)
Thanks in advance
Explanation
By default, an Azure Storage account requires secure access (that means access over HTTPS) by default.
The box you checked (Configure for HTTPS) means that the MVC Web Application is accessible via HTTPS (only). The error you're getting is that you are accessing the Storage Account over HTTP. So that's an outgoing connection to your storage account from your web application. This is not covered by the box you checked.
Solution
If you want to connect to the Storage Account using HTTPS, make sure the connection string you are using for the storage account contains/starts with DefaultEndpointsProtocol=https;. This configures the storage account client to access the storage account over HTTPS.
Additional info
The secure transfer option enhances the security of your storage account by only allowing requests to the storage account by secure connection. For example, when calling REST APIs to access your storage accounts, you must connect using HTTPs. Any requests using HTTP will be rejected when 'secure transfer required' is enabled.
EDIT:
If you're using the constructor for the CloudStorageAccount class to 'build' the connectionstring, make sure to pass in true for the useHttps parameter.
I just started building a relatively simple supply-chain app by using HyperLedger Composer webApp. In my permission file, I will have several participants that specify which role can do what. It's easy to switch role inside the playground through the wallet. However, I can't find a way to switch at my Angular webApp.
I thought it can be called through the System endpoint in the composer REST Server. But when I trying to "GET" from the /system/identities nothing show up, even I have created several participants. Can someone enlighten me with some examples?
Thank you guys so much!
Developing multi-user application using the Hyperledger Composer REST Server
Firstly, some quick background. What is Hyperledger Composer? It’s a framework for rapidly building Blockchain business networks on top of a Blockchain platform, such as Hyperledger Fabric. It’s pretty cool. You can find some more information here: http://hyperledger.github.io/composer/
Blockchain is a technology for building networks that connect organizations together. Once started, a Blockchain network allows participants to transfer assets between each other by submitting transactions, and those transactions are recorded in an immutable ledger.
So once you have your Blockchain Network how do you integrate with your client application? One solution would be to call the Hyperledger Composer JavaScript APIs directly or you could use the Hyperledger Composer REST Server in multi-user mode.
The Hyperledger Composer REST Server will generate a set of REST endpoints from a Hyperledger Composer Model. The endpoints can then be called from a client application to interact with a Blockchain. When the client applications calls one of the REST endpoints, the REST server will then submit a transaction to the Blockchain. This transaction must be signed by a certificate to say which identity is being used to submit the transaction. When the REST server is started it must be given a identity to use and by defaults all transactions will be signed with this identity.
The REST server can be configured to use authentication. This allows a client application to authenticate with the REST server and then the REST server can distinguish between each of the clients.
However this still doesn’t allow the Blockchain to distinguish between clients. The REST server will still sign each transaction with the same certificate. To enable the REST server to sign each transaction with a different identity per authenticated client the REST server must be configured to use multi-user mode. Each authenticated client will then have a private wallet on the REST server that contains the identity that will be used to sign the transaction on behalf of the different authenticated clients.
This article shows how to configure the REST server for multi-user mode and how it can be called from a client application to add participants and identities and how to submit transactions that are signed by different identities. The client app is written using Angular and will use GitHub authentication to authenticate itself with the REST server. This is just one example of the type of authentication that can be used. The REST server uses an open source library called Passport and there are over 300 plugins that are available to use, eg. LDAP, Facebook, SAML, and Google.
If you haven’t downloaded Hyperledger Composer you can follow the instructions to setup your development environment here: https://hyperledger.github.io/composer/installing/development-tools.
Once you have the development environment setup you firstly need to create and deploy a business network. The one I have used in this article can be found here: https://github.com/caroline-church/collectable-penguin-app/blob/master/collectable-penguin-network.bna. The client app used can be found here: https://github.com/caroline-church/collectable-penguin-app. The app allows users (Collectors of penguins) to sign up and to buy penguins from a “wholesaler” and each user has their own set of penguins which they have bought.
To setup the app you first need to add an OAuth application to GitHub here: https://github.com/settings/developers.
The app needs to have two REST servers running. The first has no authentication and will run in single user mode. This REST server will just be used to create participants and identities when users sign up to the app. It can be started by using the following command.
composer-rest-server -c admin#collectable-penguin-network -p 3001
The second REST server will run in multi-user mode. Firstly you need to set an environment variable to set some properties for the REST server. The and properties can be found in the github OAuth app that was created previously. The successRedirect property is set to the url of where app is running.
export COMPOSER_PROVIDERS='{
"github": {
"provider": "github",
"module": "passport-github",
"clientID": "<CLIENT-ID>",
"clientSecret": "<CLIENT-SECRET>",
"authPath": "/auth/github",
"callbackURL": "/auth/github/callback",
"successRedirect": "http://localhost:4200?loggedIn=true",
"failureRedirect": "/"
}
}'
Once the environment variable is set then the second REST server can be started with the following command
composer-rest-server -c admin#collectable-penguin-network -m true
The client app can then call the REST endpoints. To start the user needs to authenticate with GitHub. This can be done be having a link on the page, the URL is the URL of the multi-user REST server e.g
Sign in with github
Then the user needs to sign up to the app. This data can then be used to create a participant and identity. In this case a Collector participant will be created.
The following will create a Collector participant using the single user REST server
return this.httpClient.post('http://localhost:3001/api/org.collectable.penguin.Collector', collector).toPromise()
The body of the post should be the data the user supplied e.g.
const collector = {
$class: 'org.collectable.penguin.Collector',
collectorId: 'carolineId',
firstName: 'Caroline',
lastName: 'Church'
};
Once the participant has been created then an identity can be issued for that participant, again using the single user REST server. The response type must be set to blob as this endpoint returns a business network card.
return this.httpClient.post('http://localhost:3001/api/system/identities/issue', identity, {responseType: 'blob'}).toPromise();
The body of the post should include the ID and participant created previously e.g.
const identity = {
participant: 'org.collectable.penguin.Collector#carolineId,
userID: carolineId,
options: {}
};
The newly created identity can then be added to the wallet of the multi-user REST server. The card from the previous call to the endpoint is used to create a new file object, this file object is then used to create some formData. A header is added to the request to set the content type to be multipart/form-data. The wallet import endpoint can then be called with the data. The withCredentials option is set in-order to create a cookie to pass the authentication token to the REST server.
const file = new File([cardData], 'myCard.card', {type: 'application/octet-stream', lastModified: Date.now()});
const formData = new FormData();
formData.append('card', file);
const headers = new HttpHeaders();
headers.set('Content-Type', 'multipart/form-data');
return this.httpClient.post('http://localhost:3000/api/wallet/import', formData, {withCredentials: true, headers}).toPromise();
Now the client is authenticated with the REST server and an identity has been added to the wallet the endpoints can now be called. The REST server will submit transactions that are signed with the identity that was previously added.
For example the following HTTP request will get all the available penguins
return this.httpClient.get('http://localhost:3000/api/queries/availablePenguins', {withCredentials: true}).toPromise();
And the next HTTP request will get the penguins that the authenticated user owns
return this.httpClient.get('http://localhost:3000/api/queries/myPenguins', {withCredentials: true}).toPromise();
So now you know how to create a multi-user application using the Hyperledger Composer REST Server! But one last thing. If you have tried running the app you may have noticed alot of pictures of penguins. These are all penguins owned by the Hyperledger Composer team and are given to (or thrown at) people who break the build!
https://medium.com/#CazChurchUk/developing-multi-user-application-using-the-hyperledger-composer-rest-server-b3b88e857ccc
I am a developing an Rest API in spring boot and it has to be consumed by an IOS Application.I have implemented JWT token with Oaut 2.0 as security and my web server is having SSL.So the call will be made by
https://server:port//dataurl
with the header as the token. My question is since My web Server is having SSL so the connection channel will be secured (because the token should be passed in a secure channel ) or do the client side (IOS App) should also have to implement SSL Certificate. I am a having a little confusion about how the SSL channel communication. Any help is appreciated.
This link has a nice graph about how SSL works.
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10660_.htm
You can have a look of AFNetworking, no matter you want to use it or not.
In particular, have a look of AFSecurityPolicy.h and how it is used in AFURLSessionManager.m. That could be a good start point.
I am attempting to setup a freeradius server to authenticate against a web service. The reason for this is that there is a complicated workflow involving account status and mac address. The workflow seemed out of place to be in freeradius. So my user names, and encrypted passwords are stored remotely to the radius server. Everything works fine using radclient to test. When I started using the the Access Point, I learned it only communicates with the radius server via eap-tls. This means that the User-Password argument is not available for my script.
Is there a way to have eap auth check for user authentication against my script? By this i mean, can i get the password to send to my secondary service?
Alternately, is there a way to get the User-Password from the encrypted eap-message data?
Access points don't usually place restrictions on the EAP type. The device connecting to the AP negotiates an EAP type with FreeRADIUS. If it's using EAP-TLS it's probably a windows machine that hasn't been configured to do anything different.
Investigate EAP flavours to find out which ones are available. If you have EAP-TTLS-PAP you can send the plaintext password from the wireless client, and user it to authenticate against the web service.
In FreeRADIUS v3.0.x there's a rlm_rest module, which can perform basic auth on behalf of the user, with very little configuration.