In my application I am listing all the users in a Google Apps domain. I have a Service Account that I use to authenticate my application. So far so good.
Before listing the users, I need to provide a user account that my application can impersonate, like this:
new GoogleCredential.Builder()
.setTransport(HTTP_TRANSPORT)
.setJsonFactory(JSON_FACTORY)
.setServiceAccountId(serviceAccountEmail)
.setServiceAccountScopes(asList(scopes))
.setServiceAccountUser(usernameToImpersonate)
.setServiceAccountPrivateKey(privateKey)
.build();
That works fine, but I have two issues:
I currently don't store the admin account username, so I need to jump through some hoops to get that in, and in some cases I will have to ask my customers.
The account given as an admin account (having access to the Admin SDK) might not have admin rights forever. If the customer decides that someone else should be admin, my application won't work anymore.
Is there a way around this? I have permissions to impersonate any user in the domain, which means I can just pick one of the admins, but the problem is that I don't know who's the admin until I have made this request. Catch 22.
I thought I could just use the Service Account Email instead of a real user email (which would be the ideal solution), but that just gives me weird NullPointerExceptions from the Google API.
EDIT sept 25, 2014:
Since a few days ago, Google now allows any user to list users in a domain (also including subdomains).
http://googleappsupdates.blogspot.se/2014/09/new-features-in-admin-sdk-custom-user.html
However, this has two limitations which mean that this is not something I can benefit from for my particular use case.
You still need a (active) username to make a request, and how are you going to get that username if you can't list the users? I might have a username from the signup, but that account may be deleted at any time. Still catch 22.
If you are using a non-admin account, you are forced to set viewType to "domain_public", which means you will only be able to see a subset of the available fields. The "suspended" field is not one of them, and you also won't get any suspended users in the response.
(documentation available here: https://developers.google.com/admin-sdk/directory/v1/reference/users/list)
I could live with the "suspended" limitation, but since I can't get a list of users without already having a user, this is not helping me.
Related
I wanna to create an app that has 2 types of users
first type is admin: that has Authority to add info and manage the app
second type is the customer
and every one has a different options and screens
now if I used firebase with specific login with facebook, it will offer only one type of user
so how I can use the both types of users authinication ( where I begin to search ?? )
and if want to put an IF method in the code of the app ( if the admin input a specific password it will give him the access to the admin app , is this method dangerous or less security ?
You are looking for custom claims
you can assign custom claims into user accounts, you should then use those custom claims as specified in the documentation to distinguish whether that user have the required custom claims 'rights) in order to make that specific action, be it read/write to firestore or to storage.
In the application you can use those custom claims to select which UI to display for the logged in user.
The UI in itself should be just a skeleton, you should always populate the UI with data from a trusted source (a server, firestore, storage, cloud functions) in order to verify the integrity of the custom claims as a malicious can edit your code to get access to the UI.
I found a way to get login user data From Quora API. But I want to get profiles by the users' email id only. How might I do this?
It's not supported
Even the currently allowed features are only of the logged in user. So there are no ways to fetch the user profile by their id.
Quora API is still in its alpha phase and only a handful of basic fields are permited as of now. It doesn't seem to be their high priority.
Currently allowed fields are inbox, followers, following, and notifs.
Note that followers, and following return the count, not the users.
From the post regarding this on Quora Extension API.
To request particular fields about the currently logged in user, add a
fields query parameter with a comma-separated listed of desired
fields. Currently supported fields include inbox, followers,
following, and notifs. For example, to request inbox and
notifications data, go to:
Although the link is quite old, seems like no much progress has been made in that respect.
I think the answer to my question is so simple that there's not even an answer to my question lol:
How does the concept of User Authentication/User Accounts work? How does a certain webpage, for example, know to pull up your information and not someone else's when one logs in? Is it really just a bunch of select statetments with a where clause on the userid to pull back info?
When you connect to a website, a session cookie is placed in your browser. This uniquely identifies you so that the website knows from request to request, page to page, that you are the same person. Somewhere on the server, the ID in this session cookie is stored. The server knows you are there. The server knows when you click on a link that you're the same person who generated the page on which the link was present.
When you log in, the programmer authenticates your username and password against the database (or whatever he uses for user authentication), and then stores some sort of User ID on the server, attached to your session ID from your cookie. Now, whenever you request a page, the programmer checks to see if there's a User ID associated with your session ID on the server, and then knows that you're already logged in. It's common at this point, the first thing when you log in, for there to be a bunch of select statements to load your user inforamtion, any new messages, etc. This way, it can display at the top of the page.
For example, on StackOverflow, this would be your name, reputation, amount of badges, and if you have a new message.
The website never gets confused, because the cookies are never duplicated. Whenever someone comes to the website without a cookie, a new value is generated and sent to the user in the response. Then, every request after that, the browser sends the cookie value back with it. There's no way to possibly know (and it would be nearly impossible to guess) any other user's cookie ID, assuming the server wasn't also using IP address to validate session cookies. Regardless, for the programmers, this all takes place "behind the scenes". Programmers just typically access some sort of session data repository where they can store and retrieve information that is valid across page loads. As long as the user doesn't clear his cache or restart his browser, the session data will be available and unique to that user.
It depends on the underlying technology used to create the website. Usually there's a cookie stored in your browser once you log in that uniquely identifies you. Then when you load a page, the site checks the value of the cookie to see how you are and loads information appropriate to you from a database.
As an example, when you log in to Facebook it creates a cookie on your computer. Then when you go to your homepage it knows who you are based on that cookie and uses it to load your profile picture, your friends, your apps, etc.
No switch statements, though. :O
When ever we log in to our accounts, a session or cookie is created by the server. This session or cookie contains all the relevant information that the server needs to identify the user. Once server access this info, it knows which user it is dealing with and hence retrieves the users details only.
So, here's the situation. We'd like to be able to query active directory for a user's roles/group memberships, etc. Now, I can already do that using standard Java API (javax.naming), but I need a username, domain server name/address, and a password to do it. Users also have limited rights, so I can't use any external calls to fancy administrative tools.
In Java, is there a way that I can get that information with just the username and domain server name/address? I'm also open to 3rd party packages to do this. Alternatively, you could provide me with (or point me to) information on what to configure in AD to allow this.
Hopefully that makes sense. I'm not an AD guru, so the more info the better.
Your problem of needing to login first is because AD does not allow anonymous querying. Before you can query the database you must login ("bind" in LDAP terms) as a valid user with sufficient rights to issue the query.
If your AD admin is willing, you could have them create a special user (we call ours "ldapquery") that is permitted to bind and query the database. The userid and password for that user would become configuration values in your code.
Okay, so expounding on what others have told me and the vast research I had to do with the clues given here, it appears that I'd just use my "special user" as the login info in my code, transparent to the user, and then perform the query using their credentials. So: in the code, bind using the "special user", then perform the query with the current user as a query parameter (sAMAccountName=username).
Thanks all, for your input.
I'm using OpenID. How do I make it so that the user stays logged in for a long time even after closing the browser window?
How do I store and get access to the user's User object?
Basically, I guess I just don't really understand how sessions work in Java.
So you actually want like a "Remember me on this computer" option? This is actually unrelated to OpenID part. Here's a language-agnostic way how you can do it:
First create a DB table with at least cookie_id and user_id columns. If necessary also add a cookie_ttl and ip_lock. The column names speaks for itself I guess.
On first-time login (if necessary only with the "Remember me" option checked), generate a long, unique, hard-to-guess key (which is in no way related to the user) which represents the cookie_id and store this in the DB along with the user_id. Store the cookie_id as cookie value of a cookie with known cookie name, e.g. remember. Give the cookie a long lifetime, e.g. one year.
On every request, check if the user is logged in. If not, then check the cookie value cookie_id associated with the cookie name remember. If it is there and it is valid according the DB, then automagically login the user associated with the user_id and postpone the cookie age again and if any, also the cookie_ttl in DB.
In Java/JSP/Servlet terms, make use of HttpServletResponse#addCookie() to add a cookie and HttpServletRequest#getCookies() to get cookies. You can do all the first-time checking in a Filter which listens on the desired recources, e.g. /* or maybe a bit more restricted.
With regard to sessions, you don't need it here. It has a shorter lifetime than you need. Only use it to put the logged-in user or the "found" user when it has a valid remember cookie. This way the Filter can just check its presence in the session and then don't need to check the cookies everytime.
It's after all fairly straight forward. Good luck.
See also:
How to implement "Stay Logged In" when user login in to the web application
How do servlets work? Instantiation, sessions, shared variables and multithreading
Well, the original reason I chose OpenID was so someone else could handle as much of the implementation and security of authentication for me.
After looking into OpenID more, it appears there is something called an "Immediate Request" (http://openid.net/specs/openid-authentication-2_0.html#anchor28).
When requesting authentication, the Relying Party MAY request that the OP not interact with the end user. In this case the OP MUST respond immediately with either an assertion that authentication is successful, or a response indicating that the request cannot be completed without further user interaction.
Because of this I think I could just store the user's openID url in the cookie, and use an immediate request to see if the user is authenticated or not. This way I don't have to do anything with my database, or implement any logic for preventing session hijacking of the long-lived cookie.
This method of doing it seems to be the way OpenID suggests to do it with their Relying Party Best Practices document.