Bear with me please. I am a layman in web technology and have few simple questions which need simple language answers.
When we login using a username and password on any website, what exact connection/relation is established with the website server? Is it that the server stores the IP address of the user and allows the user access to certain tables from the server database for a short span of time and the regular query to the server keeps the 'connection alive'?
Thanks in advance..
A login system receives a set of credentials from the user, typically an identifier and a password. It could include what is called an authentication token, which is either generated by a handheld device (so you not only have to have id and password but the token generator; it's on the equivalent of requiring both the pin and the card at an ATM), or it's generated by combining the password with something else and returning an encryption result.
The login system, once it receives the credentials, compares them to what is stored on the credential database. In some cases the credentials are sent encrypted, such that even the login system doesn't even know what they are, all it does is determine if the encryption is correct. This would mean that even if someone was monitoring the communication channel they could not use it to fake a login later.
Now, if the credential is valid, one of two things happens. For a desktop application or general sign-on, the login program will transfer control to either the rest of the program (for an application), or grants access to the system (for a sign on). When the person leaves the application or signs off the system, then everything starts over.
For a website, the login program will send the user a cookie that another part of the website can read and determine the user was authenticated and their credentials passed. This continues until the cookie expires, or the user logs out. If the user logs out, the website sends a new cookie that says the former cookie is expired.
Related
I have a working implementation of SAML (OneLogin) within an enterprise architecture.
When a guest user arrives at my application they are redirected to the company login where they enter their username / password. After that the user identity is passed back to my application and we log them in.
However, I notice that in other applications within the company I do not have to login at all. Somehow the website "knows who I am" and seems to authenticate me automatically. I presume there is some form of certificate on my pc / browser which the other applications are passing to the SAML??
Can somebody tell me the technical term or process? Is there a process whereby I simply pull the certificate from the browser or PC and pass it to the SAML? I would like my users to be able to auto-login without entering their credentials.
Thanks
There's a number of mechanisms that support an "automatic" authentication like what you describe. In the Identity and Access Management (IAM) realm, we have all sorts of names for it, but many of us call that "seamless single sign-on (SSO)".
Within a corporate environment, I would suspect that you are dealing with a one of two mechanisms: Kerberos authentication (especially if you're a Microsoft shop and log in to a domain-joined machine on a daily basis), or your machine is in an MDM-type of system, which uses a machine- and/or user-based certificate (aka PKI) to authenticate the user or user/machine combination.
Within your enterprise, if there are other applications whose users are immediately authenticated to the application without entering their username and password, then you should talk to your IAM team or your Single Sign On (SSO) administrators to understand why that doesn't work for yours.
I will also say that it's possible that your security team evaluated what information your application offers (insider financials? source code? your secret recipe? credit card data?) and decided that they would still require the user enter their username and password to get access to the data. So when you go to your SSO admins to ask, if they say that it's intentional, you should feel free to ask why and who you should talk to about it.
After a LOT of research and testing I finally have the answer to this question, and it is incredibly simple!
In summary:
I have a working solution with OneLogin that sends me to a page like this:
https://sts.companyname.com/adfs/ls
The url is specified in the config: saml->config->idp->singleSignOnService->url
However, this page requires the user to enter their username and password and, instead, I would like the system to be fully seamless.
The solution, it turns out, is simply to hyperlink to the following url:
https://sts.companyname.com/adfs/ls/IdpInitiatedSignon.aspx?LoginToRp=https://mypage.com/saml/metadata
where "loginToRp" url is the url provided in saml->config->sp->entityID
The ADFS IDP Initiated Signon will connect to your metadata schema and automatically log the user in (without the user needing to provide any credentials)
NOTE: this only applies to intranet sites in a corporate environment
I am trying to redirect my user from a html page to a jsp page which has been deployed on tomcat/webapps using .war file.
While doing so, I am also sending the session information of the user as an hidden parameter via POST method.
With the help of burpsuite tool(security testing tool) one can easily manipulate the cookie and change the username of the user logged in. How will I be able to block such kind of cookie manipulation?
You cannot control/prevent what the browser/client is sending, so do not consider the data received as fact/true. Your application shouldn't just look at the username and say "oh, it's the admin user, I show the whole admin area".
To prevent tampering the data originated from the server or at least detect changes, you use encryption or digital signatures. With encrypted data, it is not possible to change the data. You don't know how to decrypt the data and encrypt the changed data correctly since you don't have the encryption key to do so. With signed data you can still read the data but the signature makes sure that you can detect, if the data has been changed.
In your case, you can use a JWT instead of just the username. The JWT contains a digital signature which is used to check if the data has been changed. Your "testing team" can change the data but your server can see immediately that it has been changed and reject the received (changed) information.
I have a REST api written in node which uses HATEOAS. The user is required to have an account before they can access the bulk of it.
They register an account with login details, then login to obtain an access token, and then use that token in order to access any endpoints that aren't register or login.
Issuing a get to the root responds with a directory with available actions.
Q: What is the correct response from register, to tell the client what it can do next (i.e. login)?
register technically creates a new resource on the server so a 201 CREATED and a Location header would seem appopriate. However the login reference isn't the location of the newly created resource.
Should I return 201 Created with a Location pointing to the newly created user (e.g. /myaccount or /users/{id} and then include a login link in the response body?
{
_links: {
self: { href: "what goes here?" },
x:login: { href: "/login" }
}
}
Do I not tell the client at all, and require them to do a get on the application root in order to fetch a list of available endpoints. This should include login anyway. Assuming the client had to do that in the first place to get the register link it should already have login.
Expecting the client already to already have the login link feels uncomfortable as it relies on an assumption of the client's prior activity.
Requiring the client to issue another request to the root directory after registering seems mean, inefficient and unnecessary. If the client has just created a resource it seems only fair that the server should respond with what it can do with it next.
I like to have my api's act no differently than a webpage. If you want the UX of your application to be the user is taken to login after they register, then 302 them from a successful register to the login resource. And upon successful login, 302 to them to the appropriate destination (IE, if they tried to access something with no token, then take them to login, with a destination of the original requested resource). That's and important part to your #3. Having a link off the root that leads to login, but you need to protect all the other links such that they indicate (and link to) a login being required to access the resource. The client app should expect to get this login required response at any time as tokens can (and do) expire at any time.
Following on this, it might make sense to do the JWT as a cookie instead of as an Authorization Header, it would make it a bit easier for the client (they just have to setup a cookie jar)..if the client is say a native mobile app that maintains a single connection setup. If it's server to server, then auth header makes sense. I'd go about supporting both to cover both scenarios.
Continuing on the idea of thinking of the api as a web site. Why have them login after registration at all? Why not have the registering of an account end up with the login token being sent? they just set their user/pass, why make them enter it again? I realize with some more exotic architectures the register service can not perform the login action (perhaps it doesn't have the private key to sign the token), but if it is possible i'd consider it.
If you really want to stick to the 201 header (which is fine, just make sure the docs of your register relationship indicate that), then option 2 is the closest in my opinion. A location header to the URL of the account just created a 201 is pretty standard for creating a user. But, i'd not return what you've supposed there. You're kind of returning a account-created resource (the thing with the login link), but do you really need this custom resource? If you want to give some messaging back to the client (like "Account Created") in that resource then absolutely yes, but you could also just give them back the root resource.
tl;dr; Decide what you want your UX to be and then make your API implement your UX.
I have an iPhone application that needs to collect data from an online MySQL database. I've written a PHP web service so I collect the data with JSON. The problem is that everyone can see the data if they go to the URL now. How do i secure the data transfer properly?
Thanks for your suggestions.
Typically, if you are showing data private to a particular user, then each user will generally have an account (user id and password). The app will pass the user's credentials to the server before the server will provide the user's data.
You can also do something similar using SSO integration, or OAuth (ala Facebook).
In some cases, your app may only pass the username/password on the initial call and receive a session ID, which the app passes on remaining calls. This allows the server to store session data.
Even if the data isn't private to a particular user, you can use accounts to restrict access and privileges for a publicly reachable web API.
In all of the above cases encryption such as SSL (HTTPS) must be used to protect the authentication mechanisms and data transfer.
I'm assuming your data is public for all users of your app, in other words, you don't want to implement a login mechanism for your users. If you just want to make sure you return the data only to users of your app and not to anyone who happens to enter the right URL in their browser, you will need to sign your requests, so that only requests from your app are accepted by your server.
I use a secret key that my app uses to create a hash/digest of the request which the server verifies (it knows the secret key as well). Also I make sure requests cannot be replayed if they are intercepted by adding a timestamp and a nonce. The timestamp is checked to be within 10 minutes of the server's timestamp (relaxed sync) and the nonce must be unique (server keeps the last 10 minutes of nonces). This way no-one can copy the same request, the server will just serve an error if they try.
This post explains how to sign your requests in a bit more detail:
http://www.naildrivin5.com/blog/2008/04/21/rest-security-signing-requests-with-secret-key-but-does-it-work.html
I am trying to implement a simple login system with facebook, but I need users to pick a username. What I was thinking was to get all the information I need from facebook, request permissions, then add the information to the database, redirect to a form asking for a username and then add that to the database, to the same entry.
I think a transaction is needed so I don't end up with any half completed database entries. But I've only ever used them on the same page, so I'm wondering if this is safe? If it fails then there is no point where I would be telling the database to roll back the changes and it would be with a transaction open.
Is this right or will it be ok?
I think you made it more complicated than it should be :)
No need to enter facebook id into database before username as you can always grab it later.
Forward user to login screen (or better just open login popup using javascript FB API)
Once user is logged in forward them to username picking page (or better do javascript popup without page redirect)
When user is entered username request the current user id from facebook on server side (by either using graph api or fql) and then if everything is ok enter this record to database.