The Google Admin control panel provides the "Suspend Users" API privelege.
What's the API call to suspend a user?
https://developers.google.com/admin-sdk/directory/v1/reference/users/patch requires the https://www.googleapis.com/auth/admin.directory.user scope which in turn requires the (Users->Update) privelege that allows not just suspending but other operations (i.e. "Reset password", etc).
patch API didn't work for me. update API worked.
Python code:
user = service.users().get(userKey=email).execute()
user['suspended'] = True
service.users().update(userKey=email, body=user).execute();
The api call you mentioned is correct (patch or update) you just have to set the parameter 'suspended' to true and that would be enough to suspend a user.
When doing the call (for example in the website you provided) you will add the user's email and in the parameter section you can just add:
{
"suspended": true
}
Keep in mind that you have to be an administrator in order to be able to call this api.
The scope mentioned will allow you to perform all those kind of operations and because resetting a password as well as suspending a user (and other operation) are achieved using the same api call (patch/update), the only way you can restrict the use of this is by doing it programmatically.
You will have to select what kind of operations you will let the users of your app can do. but you won't be able to restrict it on the side of the scope.
Related
I'm interested in setting an xray "trace" UserID within an asp.net core web api (based on authenticated user claims contained within HttpContext User.Claims)
To me, it makes sense that if OAuth token has for example some claims containing identity information regarding the client of an api, that the xray trace have some attribute which is also contained within the claims (user email, or even custom claim)
What method do I need to call on the AWS XRay SDK in order to manually set this value?
Is there a method on an instance of AWSXRayRecorder?
Ive tried the below but this does not appear to be the solution, rather just a weak attempt or educated guess.
AWSXRayRecorder recorder = AWSXRayRecorder.Instance;
recorder.AddAnnotation("UserID", "123");
recorder.AddAnnotation("User", "456");
How does the sdk allow this type of control? Does it allow this type of control such that we can set the value of UserID?
Here you can see within the analytics tab, User is not set (showing "-")
I understand I can use annotations in a similar way, but here what I am specifically asking about is what shows on the UI above, the "User"
Ive also tried the below, however, this does not appear to have any effect on what I see on the analytics
var segment1 = (Segment)AWSXRayRecorder.Instance.GetEntity();
var segment2 = (Segment)AWSXRayRecorder.Instance.TraceContext.GetEntity();
segment1.SetUser("User1");
segment2.SetUser("User2");
I think currently you can set values like userID or user in the trace data using AddAnnotation or AddMetadata method. Would you be able to explain why AddAnnotation method is not the right usage for your use case? I don't think X-Ray SDK supports any other APIs to set such values other than AddAnnotation and AddMetadata methods.
I have my own implementation of "windows credential provider".
In some scenarios my custom credential must switch to windows default credential and the user must see the "windows credential provider" to do the login process.
How can I exit my own "credential" and call the default "windows credential"?
In new scenario of Microsoft Windows's Credential Providers, you can't direct which other provider user must use to log on to the system.
The only thing you can do is to force logon using your own provider or decline logon using your provider.
To do this you must:
Set pdwDefault to any useful value and pbAutoLogonWithDefault to true inside of call to GetCredentialCount.
Set the CREDENTIAL_PROVIDER_GET_SERIALIZATION_RESPONSE *pcpgsr parameter inside of GetSerialization method to one of the following values:
CPGSR_RETURN_CREDENTIAL_FINISHED - to do auto-logon,
CPGSR_RETURN_NO_CREDENTIAL_FINISHED - to cancel logon UI process.
In any case your provider (tile) will loose the focus. Check out this doc.
Update
You can remove your provider from entire logon process by returning E_NOTIMPL value from inside of the call to SetUsageScenario method.
User and/or Logon UI will be forced to use any other existing provider(s).
LogonUI searches for all 'enabled' credential provider on the system and call GetCredentialCount to get all credentials for each particular Provider.
One thing you can do is calling ICredentialProviderEvents::CredentialsChanged which will ask logonUI to 'refresh' the tiles.
You can disable your provider and enable the default one in some way before calling the event.
Another way to do it is to implement your own password credential in your provider i guess. This way, you can choose the index of the credential compared to the others.
I am assuming that I would be prompted based off of the documentation, which specifically states:
If your app is using the Amazon Cognito hosted UI to sign in users, the UI shows a second page for your user to enter the TOTP password after they submit their user name and password.
Under the "MFA and Verifications" section of the user pool, I have checked the following:
Do you want to enable Multi-Factor Authentication (MFA)?
Optional
Which second factors do you want to enable?
Time-based One-time Password
I have added a single test user that is verified.
From there, I followed the documentation to both Associate the TOTP Token and Verify the TOTP Token, confirming I got the secret code in the response for calling AssociateSoftwareToken and a 'SUCCESS' in the response for VerifySoftwareToken.
At this point, I believe when I use the hosted UI sign-in page, I should be prompted to enter a one-time-password after submitting my username/password, and upon successful verification of that, be redirected to the signin callback URL specfied in my app client.
However, I am being redirected immediately after submitting the username and password and there is no prompt for entering a TOTP.
I was able to get this to work by explicitly calling SetUserMFAPreference after setting up TOTP for the test account. My assumption that associating and verifying TOTP automatically changed Cognito's behavior with respect to the authentication flow of the user was mistaken. It also required me to tell Cognito to enable and use the TOTP for the user.
The crux of my original confusion was that generating and associating a software token to generate OTPs for a user did not enable it for the user. A call to SetUserMFAPreference to enable it for the user was also required. Once that was done, it worked as expected. For instance, to enable software MFA and set it as preferred:
{
"AccessToken": "xyz123",
"SoftwareTokenMfaSettings": {
"Enabled": true,
"PreferredMfa": true
}
}
There is also an admin version of the API call that can achieve the same result.
For anyone else who stumbles upon this and still isn't getting prompted for their TOTP, you may also need to clear your cookies. Even if your pool is not set up to remember user devices, without clearing the cookies you may still be able to log in without the TOTP.
After messing around with this problem, I reckon that AWS just gave up on this and moved towards using Amplify.
Use the Amplify libraries and their Amplify UI components.
The Auth component will prompt the user at first login with a QR code.
https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#option-1-use-pre-built-ui-components
I am implementing my own SecurityTokenService that's derived from the WIF's STS. Do I need to implement Cancel method compulsorily?
By default Windows Identity Foundation's SecurityTokenService is instanciated per call as stated in this article. If I do not cache anything explicitly (or do something similar), do you see anything that should be taken care of by implementing Cancel method? Does STS or WIF do something in the background that should be handled when user logs out (Cancel method is called) ? e.g. Had I been caching the token, I would have to remove it from the cache in the Cancel method when user logs out.
It is up to your implementation. If your STS does not implement the Validate method, there's no point in implementing Cancel.
The intent of Validate is that a recipient can check with your STS whether a token that is within its expiration window has been revoked (perhaps via Cancel).
FWIW, I don't think AD FS supports Cancel and Validate. Few real-world architectures use them.
Note that when a user logs out in AD FS, their session with the AD FS server is revoked. However, any tokens issued by AD FS on their behalf will still be accepted by relying parties.
I have a web application that needs to allow users using different webclients (browser, native mobile app, etc) to register. After signing in they can access restricted content or their own content (like entries they create, etc).
What I did so far: I created a jax-rs rest webservice (I'm hosting my application on glassfish) that exposes the following methods:
register - user POST's his desired username/password/email/etc; if username/email is unique, an entry for this user is created in the database (I'm using Hibernate for persistence)
login - user POST's username and password. If they are ok a UUID is created and returned to the user (this will be used as a token for future requests). I have a table called logedusers, with userID, token, validSince as columns.
Here is where it gets confusing for me.
Let's say that I have another method, getUserEntries, that should return all the entries made by the user. To make this clearer, there will be a Entry table with the following fields: entryId, userId, text.
What is the best approach here?
What i do now, is I make a get request and pass in the token like this:
localhost:8080/myApp/getUserEntries?token=erf34c34
Afterwards, if the token is valid, I get the userID from the logedusers table and based on that userId, get all the entries and return them as json.
Something like this:
#GET
#Path("getUserEntries")
#Produces(MediaType.APPLICATION_JSON)
public Response getUserEntries(#QueryParam("token") String token) {
String userId=getUserIdFromToken(token);
if (userId == null){
return Response.status(Response.Status.UNAUTHORIZED).build();
} else {
//get some data associated with that userId, put it in the response object and send it back
return Response.ok().entity(response).build();
}
}
However, what happens if I have more methods that provide data if they are called by a valid user?
I'd have to do this check at the beginning of every method.
I want to make this authorization process transparent
So, two major questions here:
Is this design ok? The whole authenticate with user/pass, server creates and stores and sends token to the user, user sends token on future requests.
What do I do if i have many endpoints that need to determine the identity of the calling user? Can I mark them with some annotations, use some sort of security provider / authenticator (where I can add my own logic for validating - eg check to see if the token isn't older than 5 days, etc).
Thanks
Is this design ok? The whole authenticate with user/pass, server creates and stores and sends token to the user, user sends token on future requests.
It's somewhat OK. The conceptual level isn't too bad (provided you're OK with self-registration at all) but the interface needs a lot of tweaking. While yes, POST to register and login is correct, for the rest of your webapp you should be pulling the identity information out of the context if you need it, and using role-based access control at the method level where you can.
Note that your container has a whole set of authentication and authorization-support mechanisms built in. Use them.
What do I do if i have many endpoints that need to determine the identity of the calling user? Can I mark them with some annotations, use some sort of security provider / authenticator (where I can add my own logic for validating - eg check to see if the token isn't older than 5 days, etc).
Do they need the identity? Or do they just need to know that the user is allowed to access them? If the latter, the easiest method is to put a suitable #RolesAllowed annotation on the method, at which point (with suitable configuration; see the JEE5 security docs). If the former, you need to get the HttpServletRequest object for the current action and call its getUserPrincipal() method to get the user's identity (or null if they've not logged in yet). This SO question describes how to go about getting the request object; there are a few possible ways to do it but I recommend injection via a #Resource annotation.
What I wouldn't do is allow users to normally provide their own identity via a #QueryParam; that's just wildly open to abuse. You can allow them to ask about other users that way, but then you need to decide whether you are going to tell them anything or not based on whether the current user is permitted to know anything about the other user. That's the sort of complex security problem that comes up in a real app, and is a good point for needing the current verified user identity.