I created a composer supply chain application and whenever I run it using admin card on REST server and generated angular app with yeoman, I am accessing the network as admin user with the access to all the functionalities (creating users, assets or triggering all transactions).
How can I access the network as one of the participant with the permissions that I defined in the .acl file?
First you should issue a new identity for the participant. This can be done using either the API, the command line, or by using ID cards in the Hyperledger Composer Playground.
See: https://hyperledger.github.io/composer/latest/managing/identity-issue
Then you should bind the identity created to be used by the participant to interact with the business network in the context of that participant.
See: https://hyperledger.github.io/composer/latest/managing/identity-bind
You can also enable the authentication to the rest server and then create and bind the cards for the authenticated user: https://hyperledger.github.io/composer/latest/integrating/enabling-rest-authentication
If you want to test it more easily and quickly you can do it via Hyperledger Composer Playground: click on the button on the top right (where you see 'admin') and then on ID registry. From this page you can now create and manage new identities.
Related
Currently, I'm following this doc to use Oauth to copy data from Rest connector. I applied the suggested temple ,when I configure this web activity, as for the body content, it show I should provide below parameters. I wonder where to get this parameters?
screenshot2:
These are app registration ID and password.
You need to register an app in Azure AD.
Below MSFT docs provides details about the same:
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal
Here, you have to create a service principle in the Azure Active directory :
First you have to register the App under the blade of AAD > App registrations > New Registrations.
Once you register the App you have to then Assign a role under the Subscription Blade> selecting the subscription proceeding with Access Control(IAM)
Then you have copy the tenant ID and app ID under the AAD> App registrations> Your App
As there are two options for authentication one for uploading certificate and other for New Application Secret: Go with the 2nd one
Then you have to set the client secret for the New client. here is the Microsoft Document: Option 2: Create a new application secret
I'm using the Swift AWS Mobile Hub Helper to build my iOS app and connect to my DynamoDB database. I can see that after logging in using a Facebook SignInProvider I'm getting an assumed role arn for an authorized role for the table I'm trying to connect to, but when I try to use the load method on my DynamoDBObjectMapper I get an error telling like this:
is not authorized to perform: dynamodb:GetItem on resource
I tried downloading a new base app from the mobile hub page and making no other alterations but to point it to the new table but it had the same error. My colleague is building an android version of our app and he is able to connect to the database and he says that he made no changes to how he connects so I'm unsure as to what is causing the error.
EDIT: I've been looking at the federated identity pool that I'm ostensibly being assigned and the identity id that cognito is assigning my device (the simulator) is appearing there if I search for it with the dataset that my code is creating.
For each table in your Mobile Hub app, Hub creates an IAM role policy, and attaches it to the policy your users assume. If you look under your auth/unauth roles for the app (it will have the Mobile Hub project name in it). You should see a list of attached policies. One of those policies will be for the table you created in Hub. If you want that policy to have expanded capabilities, or in your case give access to a different table. You will either need to edit the policy or create a new policy.
I am trying to automate the entire process of creating a google apps account through my company's reseller account with google, without any human having to manually enable anything.
Here's a quick scenario of what I am doing.
Create Customer (Domain) with Reseller API
Create Subscription with Reseller API
Create Admin Account for the Sold Domain
I am having trouble automating step 3.
There are 2 different APIs that can accomplish this tast, Provisioning (depricated) and Directory.
I have already successfully created user accounts with the Directory API, but this step requires you to enable API access for that domain, and that can only be done manually by a human - So thats a break in automation flow, and wont work for what I am trying to accomplish.
I was instructed by google tech support to use the Provisioning API, wich is deprecated, because it supposedly allows you to create an admin user without the need to enable the API access manually per domain. When I attempt to do this, I face this error:
Uncaught exception 'Zend_Gdata_App_HttpException' with message 'Expected response code 200, got 403 <HTML> <HEAD> <TITLE>You are not authorized to perform operations on the domain mydomain.com</TITLE>
Here's the code im attempting to run:
// .....
$customerid = "somedomain.com";
$client = Zend_Gdata_ClientLogin::getHttpClient("mylogin#foo.com", "mypassword",Zend_Gdata_Gapps::AUTH_SERVICE_NAME);
$gdata = new Zend_Gdata_Gapps($client, $customerid);
$gdata->createUser('Admin', 'Firstname', 'Lastname', 'somerandompassword', TRUE);
//......
When I consulted google tech support, they told me I needed to enable the provisioning api following the same instruction I posted earlier (enable api access per domain). I have done this on both my reseller domain, and the customer domain Im trying to provision on (just to test, becasue the entire point is to be able to make an admin account WITHOUT enabling it on the customer domain.) - But it still returns this error.
Here's my settings -- as you can see, its enabled.
In google's docs, under "Enabling the Provisioning API", it has some instructions, but they appear to be out of date and dont really reflect sections available in the current google apps admin panel.
Im at a loss. Am I missing something obvious, or is it just not possible to do at this time?
Just for reference, I have found a few other people asking a similar question, but with less detail:
Google Reseller Customer Admin User Creation Admin SDK How
How to create the domain administrator of a Google Apps domain purchased via the reseller API
EDIT: Added image showing settings, and code sample.
try to delete "TRUE" parameter in createUser , it's works for me.
$customerid = "sampledomain.com";
$client = Zend_Gdata_ClientLogin::getHttpClient($email, $password, Zend_Gdata_Gapps::AUTH_SERVICE_NAME);
$gdata = new Zend_Gdata_Gapps($client, $customerid);
var_dump($gdata->createUser('trial', 'Firstname', 'Lastname', 'somerandompassword'));
in Google app console
domain settings ->user settings
check the box "enable API access"
in Google app console --> advanced tools --> Manage third party OAuth Client access
Add the scope :
https://apps-apis.google.com/a/feeds/user
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'm just getting started with D2L and am running into problems.
On the "Getting Started" page, I have completed the first three steps:
1) Acquire an App Key/ID pair from D2L - I have received the App ID and App Key
2) Create a test account in your host LMS - I have created a new user account with the administrator role for testing
3) Choose a client library to work with - I am using the PHP SDK
4) Authenticate with your LMS - This is where I'm running into trouble.
When I use the Getting Started sample:
http://samples.valence.desire2learn.com/samples/GettingStartedSample/
And enter my host, app ID and app key and hit on the "Authenticate" button, I get a "This application is not authorized on this LMS instance. Ask your administrator to authorize this application" error.
I am an administrator on my D2L host and I'm not sure how to authorize my own app.
I have tried the following:
Navigating to the "Manage Extensibility" page because that's where D2L says my app should be located, but it isn't there.
Enabling the API (d2l.Security.Api.EnableApi) under the "DOME" page to no avail.
What am I doing wrong?
Based on your question and comments, there were two issues here:
First is that the list of App ID/Key pairs appropriate for your LMS get regularly fetched by your LMS from the D2L KeyTool service. The schedule for this fetching is once a day; accordingly, if the scheduled task isn't set up, or if your LMS isn't identifying itself properly to the KeyTool service, or if time hasn't yet elapsed after key granting to the next scheduled run of the task, the App won't yet be in your LMS' Manage Extensibility list. It sounds like you no longer have that issue.
Second is that the Valence Learning Framework APIs' authentication process (requesting and retrieving a set of user tokens for an LMS user) requires several LMS features to be properly set up: (a) the LMS must be configured to support Deep Linking, (b) the LMS must be set up to handle the ?target= parameter on incoming client URL requests, and curate that parameter throughout the user authentication process.
In cases where your LMS is not doing the user authentication but depending upon another, third-party IDP (like Shibboleth), any ?target= parameter passed into the login process must be taken care of by the IDP and properly handed back to the LMS after user authentication. In a situation where you have multiple redirections occurring during user authentication, this can involve successive generation of a target parameter, and each generation must re-URL-encode the previous request URL in its entirety (like sticking an envelope inside another envelope, inside yet another envelope).
If your LMS is not properly configured to support these two points, which you might not notice during other operations, then client calls to the Learning Framework APIs won't work because the calling client won't be able to fetch back a set of user tokens.
To solve the second of these issues, you may have to contact D2L's Customer Support desk -- they can verify, and adjust as necessary, the LMS configuration part of this authentication chain. If you're integrating your LMS with other third-party IDP components not administered or deployed by D2L, then you might also need to adjust their configurations: D2L can likely advise on what needs to be done there (curate the target parameter on URls), but cannot adjust the configuration for you in those cases.