I have to implement the password expiry policy in Amazon cognito. I have checked the documents but didn't find any solution for this.
Unfortunately AWS doesn't have any built in password expiration for congnito. You can however have your own implementation by creating a new custom field that tracks the timestamp when password was created/changed. You can then use AdminResetUserPassword when the timestamp is too old. You can have a lambda query all users and check this parameter daily. Update the timestamp and reset the password if it is too old.
Related
I'm having trouble implementing a feature where I need check if a user does not exist or is existing in cognito but as federated user. The prior is done without trouble but I'm stuck on the latter without any clue. I went through the cognito and amplify documents but couldn't find any clue. Could there be a work-around or a function that I don't know about, any suggest is welcomed.
You can create a mutable custom user attribute on Cognito such as isFederatedUser and set this on user during user creation.
If this is not possible, you can call list-users and filter the identities attribute.
I have tried creating a new application and setting the expiry time to -1 on the UI for the store which looks like it worked based on what I saw on the UI. However when I tried a curl to get a token it defaulted to 3600 seconds still.
I then looked into it and found another way in which I can edit the identity.xml default to be -1 and restart WSO2. Apparently that is supposed to change it for all new applications and leave existing ones as is. So I did that and created a second new application. Again the UI looked like it was working but when I did the curl for the token it was still 3600 seconds.
Please could someone tell me if I am missing something or have done something wrong. I need to create just one application that has a token that never expires ( or at least lasts an extremely long time )
Thanks
When generating the Token from the Store UI, the API Manager uses the Client Credentials grant to generate the Access Tokens (explicitly passing the validity period).
As per the shared comment, you are trying to generate an access token using the Password Grant. In such a scenario, we can perform the following configurations (Doc) to generate the User access token with an infinite lifetime
Configure the identity.xml to configure newly created applications with an infinite token span
As you have already performed, update the UserAccessTokenDefaultValidityPeriod value in the <apim>/repository/conf/identity/identity.xml with larger values (example: 9223372036854775) to generate a long-lasting token
<UserAccessTokenDefaultValidityPeriod>9223372036854775</UserAccessTokenDefaultValidityPeriod>
Once the configurations are made, please do restart the API Manager node to take effect on the changes and try the scenario again with the Password Grant with a new Application
Hope this helps to achieve your requirement
I have a requirement to be able to specify session timeouts on a per user basis. (So that it may be a different value for each user) It seems natural to use the 'exp' property on the access token to accomplish this, (as that it's purpose in the oauth spec), but cognito seems to ignore updates to this in the preTokenGeneration trigger. Is there a way to update this on a per user basis? Or do I really need to define some custom attribute that will be checked on the Id token?
Great question. I'm sure you know that since August 2020 Cognito allows you to configure access token expiry time from 5 mins to 1 day. The configuration is per app client. If you were able to split your users across app clients that could be an option (e.g. admins with long sessions login on one page, normal users on another). You could lock the app clients down to certain users using a pre-authentication trigger. That's not a very configurable solution though.
I also wonder what you mean exactly by a session? For example, this would typically mean one of two things. Either your session expires and you have to login again after a fixed length of time (e.g. AWS is 24 hours). Or if you are idle for a certain amount of time (say 30 mins) your session is ended. Could you elaborate on your requirement a bit?
I edited a custom value on Cognito with this command:
aws cognito-idp admin-update-user-attributes --user-pool-id us-east-2_XXXX --username some_email#gmail.com --user-attributes Name="custom:address",Value="Some values"
But I put the wrong email. Is there a way to rollback that change or retrieve the old data for that user?
You will not be able to roll back the change and the data will not be available unless you had it stored elsewhere prior.
The requirement is to find user password expiration time.
Now in ldap, you enforce expiration through password policy.
The password policy attribute pwdMaxAge specifies after how many seconds from the time the password was changed does the password expire.
ldap password policy
The moment you change/create user password, the operational attribute pwdChangedTime gets added with the timestamp.
Sadly, ldap does not add any operational attribute for the expiration time, it's something we need to calculate, by doing a pwdChangedTime + pwdMaxAge < current_time
In your mods-enabled/ldap file you can fetch the pwdChangedTime attribute. Cool! But how do I fetch pwdMaxAge attribute. This file only has structure for users, groups, profiles, clients but not for the password policy. raddb mods-available details here.
(I can do this programmatically, by writing code/script for fetching these attributes using cli and then doing my manipulation, but is it possible doing this through the config? Coz, if you look at it, this expiration time is something related to user attribute and there should be a way to return it along with bare minimum user data like name and organization that we return)
Thanks!
There is no such operational attribute pwdMaxAge in the user's entry.
The password expiry warning during checking the password is returned by the server in a response control if the client sends the bind request with the appropriate request control (see draft-behera-ldap-password-policy, section 6.1 and 6.2).
This means that the LDAP client (FreeRADIUS in your case) has to support this. Furthermore all intermediate components (RADIUS server, Wifi access point, etc.) have to propely handle the response and return some useful information up the chain to the user. In practice this does not really work.
Therefore I'd recommend to send password expiry warning via e-mail. There are ready-to-use scripts out there like checkLdapPwdExpiration.sh provided by LDAP Tool Box project.