I created a cognito user pool with some apps and attributes. All is empty, it has no user yet.
Now, I want to add some new attributes in "Atributes" tab, but all fields are disabled.
On the other hand, in Federated Policies, i was trying to change the "user pool id" and "client id", under tab "Authentication Provider" > "Cognito". All fine, I do my changes and I press "Save Changes", but when I refresh the page to see it, i see that my changes was lose.
My question is, is a bug of Cognito, or updating attributes/configuration is not supported?
EDIT 1: OK, it's not possible to update an attributes.
EDIT 2: I can't update configuration on Identity Pool. Here is my steps:
Go to federated identities
Press edit identity pool
In authentication provider, in cognito tab, unloock user pool id and app client id
Update values and press Save Changes
System show me that changes was successfully saved
Go to Authentication Provider, under Cognito, but still appears old values
Check if Pool Id and App Client Id was correct
Thanks
Part 2: Changing user pool id and the client id is somewhat confusing (some would say "inane" because it is non-standard and serves no purpose). Here is how it works, there is a little "UnLock" button next to each field, you must press this button to "unlock" the field, then you can enter the field and click Save. This is handled similarly on some of the other authentication providers (google/facebook). While the "Unlock" buttons sound like the do something undesirable (who wants to Unlock their own authentication provider?) they just unlock the text field.
Part 1, to expand on Rachit's answer: You can add custom attributes, but the standard attributes are "locked in" upon creating the pool (the Console has a note indicating that).
Updating the standard attributes is not supported in Cognito. You can add custom attributes if need be.
Updating the configuration should work in Federated Identities and I just tried to reproduce and was able to change the user pool id and the client id. Is there any error message displayed for you?
I was did exactly what you did and it worked. So maybe it is fixed, or maybe you have a browser incompatibility (I did it in safari).
You can also (alternatively) add another provider using the same user pool ID (that also works).
Lastly, and with caution...
there have been reports of where configurations have gotten messed up and deleting the identity pool and reconnecting the user pool improved things. I even experienced this personally. But I was never able to reproduce it and there are risks.
risks
(the identity pool keeps the identityID and if you delete it your devices will have old keychains with non-existant identityId's and you may have to wipe the keychain
Obviously if you have anything synced it will be lost, and if you have any data related to the identityId it will be lost (because everyone will get a new identity id).
But it is a step of last resort that is easy if you are still in development.
I was facing the exact problem described in the question but able to overcome it using AWS CLI, I could add the Cognito Authentication providers, the command is as follows:
aws cognito-identity update-identity-pool \
--identity-pool-id "<IDENTITY_POOL>" \
--identity-pool-name "<IDENTITY_POOL_NAME>" \
--no-allow-unauthenticated-identities \
--cognito-identity-providers \
ProviderName="cognito-idp.<USER_POOL_ID>",ClientId="<USER_POOL_APP_CLIENT_ID>",ServerSideTokenCheck=false
Caution:
This will overwrite the existing Cognito Identify Providers, if you don't want to overwrite but add a new one then list other Cognito Identity Providers as well in the above command like ProviderName="cognito-idp.<EXISTING_USER_POOL_ID>",ClientId="<EXISTING_USER_POOL_APP_CLIENT_ID>",ServerSideTokenCheck=false next to each other, in that case the command will look like below:
aws cognito-identity update-identity-pool \
--identity-pool-id "<IDENTITY_POOL>" \
--identity-pool-name "<IDENTITY_POOL_NAME>" \
--no-allow-unauthenticated-identities \
--cognito-identity-providers \
ProviderName="cognito-idp.<USER_POOL_ID>",ClientId="<USER_POOL_APP_CLIENT_ID>",ServerSideTokenCheck=false \
ProviderName="cognito-idp.<EXISTING_USER_POOL_ID>",ClientId="<EXISTING_USER_POOL_APP_CLIENT_ID>",ServerSideTokenCheck=false
Related
We have multistep register form where user can set their password in step 2.
(User register should happen in step1 itself) So, we will set random password during step 1 and registering user details in Cognito user pool.
But end user submitting actual password from step 2.
Cognito will not update password (from step 2) without sending old password (random generated from step1). Cognito considers this process will be password update.
So how we need to handle this situation? or Is there any option / tricks which amplify provides to overcome this case?
More context is needed to fully understand why a random password is necessary for the user in this situation.
For example, if you are trying to create a multi-screen signup process and you don't want the user to get to the end of the process only to find out their password doesn't meet standards, e-mail already exists, etc., it may be more conducive to the user experience to check if the user already exists in the user pool first using ListUsers, collect the data as they move through the steps, and finally call the SignUp API call.
While I would highly recommend reconsidering the approach taken, the AdminSetUserPassword is a backend API call that can be used to set a permanent password for the user, although extreme care should be taken with this method to prevent the API call from being used maliciously on another user.
I wrote an app script which provides a web UI for data entry into a team calendar. I published it using G-Suite super admin account and added it as Trusted App under Security/API Permissions. "Trust domain owned apps" is checked under "Internal App Settings".
When a G-Suite user in our organization tries to access the app, he sees
"The developer of ShiftSchedulingApp, admin#_our_organization_.org, needs your permission to access your data on Google."
Those brave enough to click "Review Permissions" are taken to the next message:
"ShiftSchedulingApp wants to access your Google Account. See, edit, share, and permanently delete all the calendars you can access using Google Calendar"
Of course nobody wants to risk losing all the calendars on their Google Account and this is where it ends.
How do I get rid of this misleading message? It's not Google account, it's their organization account on G-Suite. It's not all their calendars, it's the shared team calendar only. It's adding data, not permanently deleting calendars. It's published by their administrator in their G-Suite, not an unknown 3rd party.
I spent days trying to make this message go away but no luck. App must be executed as an accessing user and not as publishing user because their user ID determines what shifts they can fill on a calendar.
I'd appreciate any hints pointing me the right direction.
I experimented with variations of the two-app approach as suggested.
The app which provides the UI needs to read the calendar to display available shifts - so I can't get away from the user authorization prompt.
Another variation I tried was having one app do everything and run as me, and another do nothing but return Session.getActiveUser(). I tried calling the 2nd one from the 1st one on the client side via XMLHttpRequest. It would be ideal for my needs - but I hit CORS error as apps URL is script.google.com but it actually gets redirected to script.googleusercontent.com. There doesn't seem to be a way to set CORS in Google App Script.
Although I was not able to find a way to avoid prompting users for authorization when executing the app as accessing user, it turns out my reasons for doing that were based on a false premise.
I chose to publish app as accessing user because I thought that's the only way to get accessing user Id - which is true for non-G Suite accounts.
However, when app is published by a G Suite account, the app can get accessing user ids within the same G Suite domain even when it's set to execute as publishing user.
Thanks Niek and TheMaster for your help!
If you just need user ID, why do you ask for all those permissions?
Possible Solutions:
2 web-apps- One running as you and another as user accessing (with only profile) permission. The second one will be the actual web interface and POST necessary information to the first one with privileges. OR
Implement your own web-app Google-sign in1
Use the least permissive2 scope3
For test purpose I added a read-only LDAP look-up via the User Store Management menu at admin, selecting the option:
org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager
After testing, I'm not able to remove this store entry at the Web console doing a "Select All" and selecting the the "Delete" icon. The command confirms deletion of the store, but after a new lookup the entry is still present. It is currently set in a disabled state, as some details are yet missing in the LDAP setup.
It displays a pop-up message like this:
Do you want to delete the selected user stores? Yes
Selected user stores are being deleted. Refresh the page after few seconds to check the new status. OK
After this issue, the dashboard login function stopped working, not accepting local LDAP store registered users. Under admin console access, the local users are still visible.
Please advice how to correct this issue.
A "kill -9 process number" solved the problem reported above and new start of the Identity server removed the web cache error. Yes, it did remove all the persistent entries.
I'm trying to get my standalone webapplication to use my Liferay 6.2 as "user store". That means I want the user to log in to Liferay and then be able to move on to another application with some credentials and user specific information passed as well. Moving on and passing information is already working, the issue I'm having right now is making sure the user-object that is passed on is the user that is actually logged in right now.
I use the LFR_SESSION_STATE_ cookie do determine the logged in user. But when I log in again with another user I get a second cookie with a different user-id. So now I need to make sure that I'm passing the correct user. The USER_UUID cookie does not contain the same uuid as provided by Liferay (as of now I didn't check if it's a hash of the uuid).
Long story short, I'm looking for a way to recognize the currently logged in user and be able to pass the credentials and additional information to my application.
I will take care of security concerns like manipulated cookies etc. subsequently. Maybe that will raise another question wenn I get to that point ;-)
I'd really appriciate any help or push in the right direction.
Thanks in advance guys ... sebastian
Some possibilities:
Make your application a portlet application
Publish your Liferay Database through LDAP (EE only) and use a separate SSO application
Create a Liferay-Hook that sets a cookie (to "/") containing the required user information - encryption and signatures are on yourself. You can create hooks that get executed on every successful login
I am developing a WCF service which can be consumed by mobile applications to authenticate users against the corporate extranet ActiveDirectory. I am using a customized version of this implementation from Microsoft. I need to implement the account lock out logic so that after n retries the account in the ActiveDirectory should get locked-out.
I tried with state-full WCF service to keep track of the failed log-ins. But the client can start over the next session and continue with the attack.
I know that the ActiveDirectory policy can be set to enforce this, but just querying the AD -like the Microsoft solution does to authenticate the user - does not lock out the user.
So, I am looking forward for a solution which will work like when log-in to Windows with incorrect password for n times the account will get locked-out as per the policy set in the AD.
I have not seen your code. So I'm guessing you have similar solution that is implemented in this example, have a look at this link
In above example, please have look at line
DirectoryEntry entry = new DirectoryEntry(_path, domainAndUsername, pwd);
this entry object would be used for authentication when you make a search call on active directory.
If you are using user/password that you want to authenticate then you need not to worry about locking it by your code. Active directory policy would be enough.
But after reading your comment I guess you have one specific user that you use to search mobile application users to check if they exist in your active directory or not. If this is the case effectively you are never authenticating against mobile users so those users never going to be blocked automatically.
I would be interested to know your answer.
There are basically two ways of doing this:
You continue the directory search method you are using, but track the number of logins for each user in a custom database, and check this database before doing the directory search.
Use the Windows login instead, and rely on AD to lockout the user. For a description of how to do this check: Active Directory (LDAP) - Check account locked out / Password expired
Edit
After seeing marc_s's comment, I am unsure if doing the directory search will lockout or not. It would actually be a serious security hole if you could try an infinate number of times. But you would need an account that is allowed to query AD before you could use it.
The code you linked to had this line
object obj = entry.NativeObject
Which was to force authentication. Have you included this line?