I'm working with hyperledger fabric in the stable version.
In the CA, the users with their password are stored in clear-text on the membersrvc.yaml file in $GOPATH/src/github.com/hyperledger/fabric/membersrvc.
Is it normal ? Is there an other way to create the users when I launch the CA without having the crendentials in clear text ?
The userid/password combination present in the membersrvc.yaml can be used only once. Think about it as an OTP. If you want to reuse it again, you have to bring down the membership service instance and you have to clean up the user data store in the /var/hyperledger/production/db directory (And as of now, as per my information, there are no plans to include a logout API which might have enabled the usage of the credentials again without clean up).
If you want to add a new user to the Fabric, then this can be done programatically with the Member.register method - while using Node.js SDK. But the user would exist only during the life cycle of the Fabric ( ie, till a clean up is performed).
Related
I'm trying to migrate from local NLTM authentication to Azure AD login for an on premise app. I have set up the connected service, but everytime the SignIn method is called:
The request is already authenticated and it's using my local PC name, so the O365 log in is never triggered. Debugging doesn't help as the User info and Request don't seem to exist outside of the AccountController. Does anyone know what is going on and how I can get it to load up the login instead?
If anyone else finds this, check and triple check your web config and project files for any lingering windows authentication variables. Failing that try creating a new project with authentication and then copy the content of the old project across bit by bit. It turned out for me to be something dodgy in the project, but even using a comparison tool afterwards showed no discernible differences.
Only thing I can think of is that the Authentication with Azure Active Directory Connected Services made changes that broke something, but using the auth option during project creation did it properly.
I am writing an iOS app and have a dilemma. The app will be used to test the BLE protocol of devices coming off our production line. It needs to be very simple, It is a one button app that automatically connects to devices and tests commands in our protocol and gives a pass or fail result. If it passes the device id is sent to our API to be entered in our database.
My problem is I don't want the user to have to login, but I need to send a username and password to the API to log in. This means the username and password has to be included in the app. I am trying to find out the most secure way to do this. I initially thought I would include a plist in the app with the credentials, enter them in keychain, then delete the plist. However I don't believe you can delete a file included in the app bundle (I get a 513 permission error).
I have 2 questions. Is it secure to include credentials in code? Is there a better way to do this?
Thanks!
No.
Use API to retrieve credentials and store to keychain. Simple call to firebase could solve this. Or use your own backend with your custom “security”.
But even obtaining via API don’t give you 100% security. Everything depends. API solution gives you flexibility and ability to support different versions with different credentials.
I am using azure AD authentication to authenticate a user in my MVC
application.And I published my application on azure and it is
working fine.
But, when I run my application locally then it Microsoft's login
page comes up and when I enter credentials and click on SignIn
button then it is giving "Sorry, but we’re having trouble signing
you in.We received a bad request."
But the same application is on azure and if I access it from there then it allow me to login.
To create this apllication I follwed link to add azure AD authentication
If you notice the error message, it clearly indicates that you have not configured https://localhost:44320 as one of the reply addresses.
Please go back to application configuration screen in your Azure AD and add https://localhost:44320 as additional reply address. That should take care of this problem.
Add the below to your Web.config. It must be the same port which you have added at the time of Application registration.
<add key="RedirectUri" value="https://localhost:44320/" />
I hit this, it has cost me a lot of time.
I would check firstly that you have the ability in Azure to access third party applications.
In Azure > Users & Groups > User Settings:
You see the first item (Users can allow apps to access their data) - without this checked I believe it wont work.
As you are running your application locally it is not published to Azure, this means that although it may be within the realms of your organisations network, Azure still views it as a third party application.
Be wary setting this to 'Yes'. I understand that there are ways to then create applications that allow you to behave as an Azure super user....
In case anyone else comes across this, here is what happened to me. I had been switching back and forth between environments within Visual Studio (Project >> Properties >> Debug >> Environment Variables). Well, the last time I switched it, I wrote "Develop" instead of "Development" to switch back. This caused .NET Core to grab the wrong appsettings which connected to the wrong AD which did not have my localhost setup on it. It took me an hour to catch what I had done wrong.
This may not be exactly what has happened to you, but do check to make sure you are picking up the Azure AD settings you are expecting if they are in your appsettings. It could be a good point to start at.
I have a windows desktop app (written in Delphi) that allows users to store and retrieve files.
The application stores these files in a single network shared folder (Active Directory).
The various users of the app do not all have permission to see all of the files, these permissions are controlled by the app.
Currently we have to allow every user of the app access to the shared folder, so a malicious user could find the directory and gain access to all of the files.
Is there a way that the app can act as a specific user such that only the "app as a user" and not each individual needs permission to the shared folder?
You need to either:
1) run the app as the desired user.
2) have your code programmably impersonate the desired user, via LogonUser() and ImpersonateLoggedOnUser(), or other similar functions, before then accessing the shared folder. Don't forget to stop impersonating when you are finished using the folder.
Not directly, no. The app has exactly the same rights as its user has. That's part of the OS's security model. If I had to deal with something like this, I'd do it this way:
Create a second program that runs as a Service, and set it to run under a user account that has access to the shared folder. It should implement some sort of validation logic, and listen for incoming messages. (What exact method it uses for this is up to you, but you're essentially creating a server.)
Your desktop app runs under the limited user accounts. To request a file, it sends a message to the server, in which it identifies the user and the request it's making.
The server checks the request, and if it's valid, retrieves the file and passes it back to the user app. If not, it should return some sort of error message.
Not with standard file sharing -- the application is always going to running in the security context of the logged in user.
There's 2 obvious solutions I can see:
Work with the AD security and user accounts you already have in place to modify the rights to the files in the shared folder. This only works if the security in your application can be mapped to AD security objects already. If you need to allow for impersonation (e.g. An administrator "logging into" the app as himself or herself from another user session), then you're going to need to get very comfortable with the various Windows Security APIs.
Write a server-side component that will handle your application's authentication mechanism and provide file listings and content to the client.
It's possible that #2 could be implemented with something like WebDAV, FTP/SFTP/FTPS, or some other "already done" file transfer protocol that you can piggy back off of to save you some work.
I want to sign a BlackBerry application with the 3 CSI files I have. When I install new keys, I give the associated user id and password, but I am getting this error:
Unable to register a client bearing no
175534 because there are no more
registration attempts. If you have
already registered with this server
then you must contact RIM to register
additional users.
Can anybody tell what is next step that I need to do?
The error message seems pretty clear on the next step:
.. you must contact RIM to register additional users.
The official response from blackberry support:
Hello,
Thank you for contacting BlackBerry Application Development Support.
This error means the keys have already been registered so cannot be registered again. To have this issue resolved a new set of signature keys will need to be issued and installed. Please note that signature keys are now completely free and issued several times a day, so the fastest way to get a new set would be to place a new order:
https://www.BlackBerry.com/SignedKeys
Prior to installing this new set of keys please first delete all present CSI files as well as the sigtool.* (DB, CSK, SET) files that will reside in the sub-directories of all development tools. Make sure to write down the PIN used to place the order as well, it will be needed when installing the keys.
After registering your keys and verifying that they are able to sign I would recommend backing them up some place safe in case anything should happen to your development environment:
http://supportforums.blackberry.com/t5/Testing-and-Deployment/Backup-and-Restore-BlackBerry-Code-Signing-Keys/ta-p/837925
Go to the first URL and request a new set of keys. You should get an order confirmation email right away. In about 1-2 hours you will get 3 more emails. Each one will have a CSI key attached. (The keys are free to generate)
To avoid this issue in the future, you can back up the keys, according to the instructions in the second link (above).
Good luck!