Need to find out when a user was suspended - google-admin-sdk

I can't see the information anywhere.
When I pull the users.List i only see if a user is suspended but not when the account was suspended. The information is visible on the user page in ADMIN, so the information has to exist somewhere.

You can get the date of a user suspension by looking for the SUSPEND_USER event in the Admin-SDK Reports API.
You can use the "Try this API" feature here: https://developers.google.com/admin-sdk/reports/v1/reference/activities/list
and provide the following values (leave other blank by default):
userKey: all
applicationName: admin
eventName: SUSPEND_USER
Further info: https://developers.google.com/admin-sdk/reports/v1/reference/activity-ref-appendix-a/admin-user-events#suspend-user

Related

wso2 identity server dashboard forgot password/forgot username not working

I followed the below steps to enable password recovery using email notification.
https://docs.wso2.com/display/IS530/Password+Recovery
When I click forgot password button on dashboard login page, it asks for username and after that throw below error
Code : 20017
Message :Notification based password recovery is not enabled
I checked code in github and found property recovery.notification.password.enable is used but could not locate in any config file or any documentation. I am using WSO2IS 5.3.0.
How can i enable password recovery through end user dashboard if not mentioned in above mentioned steps.
Assume you are following the old and deprecated method. The steps for new APIs are available at the REST API Guide, It is also linked from the section "Password recovery using REST APIs" in the page you referred.
What you need to do is enable the Notification Based Password Recovery Enabled at the Resident Identity Provider configuration at management console and optionally set the expiry time for notifications.

AWS Cognito: Google Login find the email address

Once the cognito-id is created for a user logging via. google, how to find the email id of the user.
As shown in the above picture, I can find the cognito-id, but couldn't find any other information that google could have supplied when the user logged in.
Any help is appreciated.
Thanks in advance,
First make sure you provide email in scopes. Usually the scope is defined as profile email openid.
Next you have to "Configure attribute mapping" which is on the bottom right of the "Identity providers" section. There you can map Google's email attribute to the Email attribute of the user pool.
You'd probably have to remove users from the pool that logged in prior to the additional configuration to properly fetch the attributes. You can do this by clicking on the google user in the user pool then click "Disable" then "Delete". For example, I couldn't see the picture attribute of a google user until I removed my user from the pool and logged in again.
You should now be able to see the email attribute (and other properly configured) when you click on the user. You should also be able to see these attributes when you decode the id_token and when you call the <AUTH_DOMAIN>/oauth2/userInfo endpoint.
Cognito leverages these tokens to sign in users, but doesn't store any additional metadata against the user. It doesn't track any of it, so you won't see it there. To do so, you'd need to grab it from Google during sign in, and either store it in Cognito sync or in an external datastore (e.g. a dynamo table keyed by identity id).

WSO2 APIM/IS - Is it possible to allow user to choose scopes to authorized

I am studying WSO2 API Manager. In the OAuth authorization code/implicit flow, after the user enter a valid credential in the login page. The user will be redirected to consent page like this.
When user click Approve, access token will be issued with all valid requested OAuth scopes. However in OAuth flow, application can request access to multiple scopes. Is it possible to configure/customize WSO2 API Manager consent page to present the user with the list of request scopes and allow user to choose which scope will be allowed (like Facebook) ? If it is possible please guide me to where I should look further.
Yes we do have identified this as valid requirement and created JIRA to fix this issue in upcoming identity server release. Once identity components release with this feature API Manager can use it and next API Manager release will have that. Once we have that feature you can do following changes in authentication endpoint app and get user consent for scopes.
/repository/deployment/server/webapps/ directory. You'll see the exploded directory authenticationendpoint. Then users can edit web.xml file in authenticationendpoint/WEB-INF directory and displayScopes parameter to true and save the file.
<context-param>
<param-name>displayScopes</param-name>
<param-value>true</param-value>
</context-param>
Once the change is done, you'll see an entry in the carbon log similar to Reloaded Context with name: /authenticationendpoint after a couple of seconds. The scopes will be displayed in the consent page afterwards.
Public JIRA to display scope description in oauth/oidc consent page
Thanks
sanjeewa

Create Custom Registration Pipeline Using python-social-auth

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).

How to handle the scenario "access_token changes when user changes facebook password"

I am able to see from the following link that, if password change, access_token will get invalidated.
http://developers.facebook.com/docs/authentication/
So, how to identify when user change his/her password.
I did not see anything about this in the graph api documentation.
Please help me regarding this.
Thanks,
Gopal.
When access_token is invalidated due to password change, you can no longer make Graph API calls, i.e. Graph API returns an error. You can recognize this error and set a flag in user profile which triggers a notification "Hi Gopal, you have to reconnect your account with FB. To do so, click [here]", where [here] points to the regular FB oauth url (i.e. https://graph.facebook.com/oauth/authorize).
EDIT 14/05/2011: Facebook just released blog entry on this topic: http://developers.facebook.com/blog/post/500