We're currently working with WSO2 IS server, version 5.7.0. At this time, everything seems to be ok excepting one thing.
We activated self-provisionning and we added a "Service provider" with oauth2 authentication enabled.
It created the role named "Application/myapp".
Then, going on the "authorize" form, we press "Register now" button and we can create a user. It sends validation mail, and the user is created.
But, the user is not assigned to Application/myapp role.
Is there something we can do to assign user role at registration time ?
Thanks !
I think you have confused. The register now will be redirected to the self sign up form. The users created there will be automatically assigned to the 'Internal/selfsignup' role.
There is no link with the created application and the self sign up process. The automatically created application role (Application/myapp) is for a different requirement. The users with that application role can perform the update and delete operations of the application.
Is there something we can do to assign user role at registration time?
No, you can't create a role. If you want to have this functionality, we need to have your own self sign up for the application and send the user registration request to the IS using SCIM. Here you can find the API definitions. You can use the oAuth tokens to access these APIs.
Related
I am using AWS SDK (Java) for user creation in Cognito via Admin create/signup API documented here
The docs say that the method throws AliasExistException if a user creation is attempted using an email that already exists with another user.
To my surprise, the exception is thrown but at the same time, the user is created in Cognito as well and the new user overrides the email-verified flag for the existing user.
This cannot be the intended behavior. What is the purpose of an exception if the user is anyways created? How can we stop the creation of such users? Am I missing anything?
P.S: I am sending ForceAliasCreation as False
I tried to add a user using the Web API via client credentials and via identity provider. Neither resulted in the invited user receiving an email or seeing the granted lock in his app.
I called /api/v1/Owners to get the owner account's ID for the locks I want a new user to grant access for.
I created a new contact by posting to /api/v1/Owners//Contacts only setting email as identifier (not posting any other data) and using the ownerAccountId from step 1
With the newly created contact id from step 2, ownerAccountId from step 1 and boundlock id I did a put request to /api/v1/Owners//Grants
This resulted in a 200 response, but the new contact did not get any notify or invite email.
When I login to my.portal.nl as owner of the lock I do see the the added user as smartphone user with correct lock and validFrom and validBefore
I expect the invited user in step 4 to be emailed. What am I missing? In your comment you say : Generally speaking, Tapkey will usually not send emails to users.
But how do new users get notified about new locks the can open?
Via the API I do see the users and grants are actually added. I have checked spam folders, but no emails.
When I register as one of these user by using the emailadress I setup as identity and login into the tapkey app, still no locks.
The client ID I'm using is c2f11e47604639323320d08f8e4038f4 and the owner account id is e12e4145-3afb-45ae-81f5-2cdd57d89fb5
I will just summarize what was already explained by Markus in his answer:
Regarding the question about the email:
User will not be informed by email if you create a grant for him.
Regarding the permissions:
If you have created permissions for an user with an identity provider tapkey then these grants are visible for the user once he logs in into the Tapkey app and navigates to his smartphone keys.
If you have created permissions for an user with your own identity provider, these are not displayed in the Tapkey app for a granted user and you need to implement your own application to handle these keys.
We had a look on the grants you have created and as you correctly said, they were created successfuly. All, but one, have been created with your own identity provider and therefore they are not visible in Tapkey app for the granted user. Due to the privacy reasons, I don't want to share anymore details regarding your data here.
Amplify CLI authentication with Cognito user pools currently has two main modes, signin with username or with email. In the former case email uniqueness as a required user attribute is not being enforced.
Cognito service by itself supports the "Also allow sign in with verified email address" option (AWS Console, User Pool Attributes-section) but it can be set only upon user pool creation (i.e. can not be modified later - checkboxes are disabled). Is it possible to enforce no duplicate emails within the user pool while allowing users to authenticate with username or with email?
To summarize, my use case requires:
Verifying/enforcing email attribute uniqueness at the Cognito level when signing up users via Amplify's Auth.SignUp;
Keeping username-based login but allowing users to login with their email as well (that is, Auth.SignIn with email or username supplied as the username-argument).
When you add the user pool with amplify add auth choose 'Username' as the method with which you want users to sign in when prompted.
If you aren't prompted with this choice, you might need to try amplify add auth again but this time choose Manual configuration when prompted at the beginning.
Once you've completed the entire auth set up via amplify add auth, BEFORE you run amplify push for the first time, run amplify override auth.
This creates a new override.ts file which you can edit with AWS CDK code to customise your Cognito resources beyond the abilities the CLI allows.
You can find the override.ts file at:
amplify\backend\auth\<your_app_name>\override.ts
Inside the override file, add the following line into the empty function that's made for you:
resources.userPool.aliasAttributes = ['email'];
Now you can save the file, and run amplify push and hopefully your new user pool will show in the AWS Console that you've successfully configured it to allow user name and email sign in together.
You have to make sure you write the override code before amplify push or your user pool will be created in the cloud, and attempting to override this sign in functionality after the user pool has been created throws an error as it's read only.
If you find yourself in that position, you'll need to create a new user pool, you can't modify the existing one.
I am using Facebook Ad Api to create ads. How ever when i grant a user Administrator Role (1001) with the following api call:
https://graph.facebook.com/v2.5/<AD_ACCOUNT_ID>/users?role=1001&uid=xxxxx
it successfully creates the user, and when i get all the users using the following request:
https://graph.facebook.com/v2.5/<AD_ACCOUNT_ID>/users
it successfully returns the array as:
"{"data":[{"name":"firstname lastname","permissions":[1,2,3,4,5,7],"role":1001,"id":"101xxxxxxxxxx352"}}"
but when i try to create an Ad campaign or Adset with the newly added user the following exception is thrown:
[FacebookAds\Http\Exception\AuthorizationException]
(#272) This Ads API call requires the user to be admin of the application. User 16xxxxx351 not admin or developer for application 109xxxxxxxx0403.
And when i go to my app and assign the user with an Administrator or Developer Role, I can make requests successfully.
Why is facebook not allowing a user created with administrator role from the api not make api calls to its Ad Api ? And why does it allow when the user is granted Administrator/Developer role make requests ?
This is because the objects you can promote are not based upon an adaccount but are based upon your user.
You can see the connection objects a user has access to by make the following request:
<API_VERSION>/act_<AD_ACCOUNT_ID>/connectionobjects?access_token=<ACCESS_TOKEN>
The documentation states:
this call returns the IDs of all objects for which the current session
user is an administrator, and the IDs of apps for which the user is
listed as a developer or advertiser.
If you don't want to make additional administrators for your app, you can create system user in Facebook Business Manager, grant him administrator (or even advertiser) rights for Ad Account.
https://developers.facebook.com/docs/marketing-api/business-manager-api
And use his token to manage ads. In my case I used it to retrieve targeting of ads, to find where leads came to lead form from.
https://www.facebook.com/marketingdevelopers/videos/vb.606699326111137/883648801749520/
I have a django-based site that has private content and a small number of necessary users. I would like for everyone to use their Google account to authenticate using python-social-auth (PSA). I would therefore like to use the following process to add new users:
The new user visits the site and clicks on a "request access" button.
PSA would create a disabled user. The requesting user would be redirected to a page stating that access will be granted within 24 hours if approved.
The site admin would receive an email message notifying her of the request. If the new user is approved, then his account is enabled and the user is notified. If the request is not approved then the disabled account is deleted.
Once the user is enabled, he will login using the pipeline from this tutorial that only authenticates registered users. That part's easy. The hard part is figuring out how I'm going to register users but not authenticate them.
I tried extending the SOCIAL_AUTH_PIPELINE by adding a custom pipeline function that disables users if they're new. However, the pipeline continues to execute at that time, and it appears that it then tries to authenticate the new, disabled user. I say this because I'm redirected in my app to this URL:
http://myapp.com/accounts/login/?next=/
...which for me is a 404. This URL seems to be generated by PSA.
So here are my questions:
Is it possible for me to drop out of the SOCIAL_AUTH_PIPELINE and redirect my user to a "please wait for authorization" screen if they're a new user? I don't think that I can use a "partial pipeline" for this because I don't want to pick up the pipeline again later - I just want to "drop out" if this is a new user.
If that's not possible, then what's option B? Is it creating a custom pipeline that only handles registration? If so, then how would one do that?
You can keep your pipeline that flags the user as disabled, but also define this setting SOCIAL_AUTH_INACTIVE_USER_URL = "/wait-for-activation" (point it to the URL that shows the "wait for activation" page).