There are varying levels of data that a given user may have access to. I want to configure an endpoint so that last time the user supplied their credentials defines the level of authorization they have.
e.g.:
> 1 hour = level 1
< 1 hour > 10 minutes = level 2
< 10 minutes = level 3
I looked at the time-based policy but that does not appear to do what I want. I prefer to leverage keycloak to do this rather than hack up the client to derive these levels itself. The user should be able to request a resource, and the credentials they access that resource with define presumably the access-level (role does not appear to be appropriate for this case), which defines what they have permission to read vs. what would be empty. I looked at the custom authenticator, but that seems only for authentication as opposed to authorization. Like a dynamic time-based policy.
Is this feasible via keycloak? And is it a server feature? How can I configure something that changes with time?
This purely seems like a Server feature and you've to program it internally based on the keycloak access token expiration time.
Keycloak's Time based policy covers the authorization of a user under certain period of time (A user can access app/api/webpage only in the period of time for which time based policy has been implemented, a user accessing the feature before or after time-based policy's mentioned time can not access it). it doesn't cover the hierarchical authorization level that you require.
The only solution i can find to your problem is JavaScript-Based Policy , though you still need to define the rules programmatically as defined in documentation:
You can use this type of policy to define conditions for your permissions using JavaScript. It is one of the rule-based policy types supported by Keycloak, and provides flexibility to write any policy based on the Evaluation API.
Here you can read in details regarding Javascript-based policies:
https://wjw465150.gitbooks.io/keycloak-documentation/content/authorization_services/topics/policy/js-policy.html
So, keycloak doesn't provide any solution for your problem out of the box, you've to do it programmatically inside your Server or through Javascript-based policies
I want to create a login system using JWT and have these questions:
1- My client login and I generate a token for him/her and store the token in local storage. Now If somebody else copies this token from local storage of this person browser and paste in his/her (I mean hacker) browser local storage, this hacker will able to log in? If yes, is that safe?
2- I put user Id in the token that I generated On login function. On each request that is sending to the backend, I decode token and find userId in it. Now should I compare this user id by anything? Example checking that is there any session by this user ID in backend or even checking the user Id by DB?
3- should I put an expiration time for JWT token on the local store?
1 - It's safe to store these in localStorage. It is worth checking out how to protect against Cross site scripting attacks; this is particularly true for high security environments. Users copying and pasting is probably an unlikely attack, and, if the user has physical access to do the copy and paster, there are probably other 'vulnerabilities' like just using the browser's stored passwords.
2 - The JWT encrypts the user id included in the claim. A user can't change this claim and keep it valid (assuming a strong key), so no need to check this elsewhere.
3 - Yep! Since the JWT has a claim (like the user roles) in it, you don't want those to be valid for forever. Also, you want to have a way to ensure that users re-verify their identify (ie. log in again) just in case something goes wrong/a token is stolen. When you put an expiration on the token, you force this.
I am using JNDI framework to interact with various LDAP servers specifically for Sun one LDAP, I am observing the following:
Use case: If Administrator resets password of any user in Sun-One LDAP server then passwordMustChange attribute is set to "on". As a result user has to change his/her password on next logon. This is what documented.
I am performing same action through JAVA code using JNDI. I observed that this attribute is set to "on" successfully. So programming logic is correct.
But when I logon with that user on LDAP server, it doesn't give any error or pop saying that password has expired and please change your password.
The same use case works as expected in case of Active Directory (AD ) servers
In case of AD, we need to set pwdLastSet to 0. It works and system asks to change password on next logon.
On contrary, same use case does not work for any LDAP flavour such as Sun-One LDAP, ADAM, or Open LDAP.
Please let me know if anybody has observed such issue and suggest me how to fix this.
You're setting it in the wrong place. passwordMustChange is an attribute of the policy, not of a user. It means that if you set the operational attribute pwdReset for any user, he must change his password on next login, and that is advised via a response control when he does so.
That in turn means you must use the password-policy request control when binding a user, and check the response control. It also means that you must use the change-password extended operation when changing the password, rather than just rewriting the attribute.
This also explains why you thought you had to add objectClass=passwordPolicy to the user entry. You don't. You have to define a separate policy object containing a value for passswordMustChange and the other policy attributes, and specify that in the configuration as default policy, or in the user entry as his specific policy if you're going that far.
You need to reread the documentation and distinguish clearly between policy attributes and user operational attributes. They're listed separately.
What code are you using for the extended operation and request/response controls? I had to write mine. I posted it on the Sun Java forums several years ago: is it that code? Just curious.
Unfortunately there is no standard for this kind of feature (there's an internet draft, expired and which is partially implemented in different servers).
Depending on your versions of Sun Directory Server, there are different ways to do this (SunDS 6.x introduced a new password policy based on the Internet Draft).
With 5.x, I seem to recall that the passwordExpirationTime would take a specific value when the password is expired. The server will return a PasswordExpired Control part of the Bind response saying that it has expired.
With 6.x and beyond, the pwdReset operational attribute is set to true. The server will either return the PasswordExpired Control, or a PwdPolicyControl response if you've set the PwdPolicyControl request in the Bind request.
What happens when you log into a website?
I know cookies are stored and some info (what info?) gets sent to the server...but maybe some more detail?
Once upon a time, somewhere on the Internet....
Browser: "hey, can I see this web page?, Trouble is, I don't remember speaking to you before"
Website: "sure, fill in the form, I need your username and your password"
Browser: "Here ya go"
Website: "Great!, Welcome back koldfyre! Here's the page. Look, if you want more pages, take this token and use it when you ask for another one"
Browser: Cool. That site gave me a token. I'll memorize it!
A few minutes later
Browser: "Ooh! Can I see this other web page? Here's my token"
Website: "That token looks good, hello again koldfyre, here's your web page"
That, in essence, is it. In order to remember a user has logged in, it gives the user a token which it must present with its next request. This is normally achieved by the server telling the browser to store this token in a cookie.
Delving deeper - transport layer authentication
The way the credentials are passed to the server, and the nature of the token it returns, vary depending on the authentication method employed.
The very simplest, HTTP Basic Authentication, is provided by most web server implementations. It causes your browser to pop open the familiar login dialog box. The "token" is simply your plaintext username and password base64 encoded. Not particularly secure.
A server might also provide Digest Authentication, which avoids transmission of the actual credentials - the client instead generates a hash of their credentials with a server generated salt. It is designed to prevent password sniffing and replay attacks.
Deeper still - application layer authentication
For maximum flexibility and control, most sites opt to implement the authorization in the application layer rather than the HTTP transport layer. This gives a wider variety of security choices. Any site which asks for credentials in a web page (rather than the browser's login dialog box) is using a custom authorization method.
Custom methods will vary wildly in their initial interaction, but they almost always result in the user being given a session cookie containing a randomly generated identifier. The browser then automatically presents the cookie with each subsequent request. The web application will inspect the cookie value to ensure it is still valid.
It's also possible to hand off the authorization to a trusted third party, generally to provide some sort of single-signon service. In cases like that, when you notice a user isn't authenticated, you bounce them off to the authentication provider. They authenticate them, and they will be returned to you with some kind of token you verify with the provider. Shibboleth is one example of this. You also logged into this very site using a similar method employed by OpenID
Further reading
Here's some nice answers from a similar question
PART I: How To Log In
PART II: How To Remain Logged In - The Infamous "Remember Me" Checkbox
PART III: Using Secret Questions
PART IV: Forgotten Password Functionality
PART V: Checking Password Strength
PART VI: Much More - Or: Preventing Rapid-Fire Login Attempts
PART VII: Distributed Brute Force Attacks
Other answers in that question provide even more links to round out your education!
That's a pretty general question. What you're doing, over all, is establishing some kind of credentials with the site itself. If we take the simple version, you enter a user name and a password; that means you identify yourself to the website, and then show it a secret you and the website share that no one else knows (we hope). That establishes you as authentically the person with that user name, and so we say you have authenticated yourself.
Once you've done so, there are some design decisions the website designer has to make. most people don't want to log in for every page, so the web site wants to store a little information, a credential, on your end. This means that it can tell it's still you. Often, as you say, that's a "cookie", which is nothing more that a tiny text file named with the web site's URL. This file is stored by the browser.
On many web sites, like for banking, you also want to guarantee that the data being exchanged can't be intercepted by a third party. If so, you establish a secure connection using a protocol known as SSL or TLS. What this adds to the basic connection is an exchange of information that establishes a session key. This session key is then used to encrypt the communications. This usually happens before you exchange the user name and password, so that your password is never visible to a malicious third party either.
Under the covers, when you establish a secure connection, the web site sends your browser a block of formatted data called an x509 certificate. This is another form of authentication; the certificate will have been signed by an issuer (the certificate authority or "CA") and the browser can use stored data about the CA's to ensure that the certificate is authentic.
This completely depends on the implementation of the website. Even the usage of cookies is not mandatory, but very common.
In most cases however, something like this happens:
You send in your username and password using an HTML form.
The server looks up the relevant user (using a database)
The server checks if the password matches the password that is stored in the database alongside the user.
If the password is correct, the server will store what user currently is active in the session. The identifier of this session is stored in a cookie, the actual data of this session (the current user) is stored on the server under this identifier.
Now you are logged in. You will remain logged in during the remainder of the session:
When you request another page from the server, you will send the cookie with the sesison identifier.
The server loads the session using this identifier. In this session, the current user is stored, so the server knows what user is logged in.
When you log into a web site, first your credential are authenticated. If your credentials match, then something is put into the session (on the server) to keep track of who you are so you can access data that is yours without having to re-log-in. This is obviously useless on the web server unless the client can provide information about who it is on each request. Note that the "Session" is usually maintained entirely on the web server, with the client having only a key that allows access to the session.
Remember that HTTP itself is a stateless protocol. The HTTP standard contains no method for HTTP requests to keep or persist any state between individual HTTP requests. Thus, the state is usually kept entirely on the server and you just need a method for the client to identify which session the current HTTP request belongs to.
The two common ways this is done are:
Use a cookie (for example, Apache Tomcat uses the JSESSIONID cookie) to store some hashed authentication token that will successfully look up the web session, or
rewrite the URL so that every request has the session ID added to the end of the request. Still using Apache Tomcat as the example, if cookies are disabled then the URL will be rewritten to end with a string like ";jsessionid=....". Thus, every request, every HTTP GET and POST (and the rest) will end with this string.
Thus, on each request the client makes, the session ID is provided to the web server, allowing the persisted state for this client to be quickly looked up, allowing HTTP to act like a stateful protocol.
What information is sent to the server when you log in? Whatever information you provided on the login form. Some web servers also track the TCP/IP address the request came from to avoid session hijacking attacks. This is usually all the information that is needed by the server.
If you don't allow your browser to save cookies, then you will have to log in to the web server each time you open your browser and initially open the server's web page. However, if you allow your browser to save cookies, then many servers allow you the option of saving the cookie (that is, not just using a session cookie) so that each time you go to a web page of the server, the persisted cookie will identify you so you don't need to re-login. Here, the cookie will save enough information -- often in an encrypted form that only the server can understand -- to identify you. In this case, the Cookie is not a simple session ID.
Very simply explained, what happens is mentioned below:
What goes in?
Username
Password
What happens inside?
Password is converted to its hash
Hash(password) is compared with the DB table or a Directory Service
(unless someone is down-rightly foolish, the site won't save your password in clear text)
If Authenticated, A status-token is stored in Session and/or cookie.
This token can just contain a status, Login Timestamps, your userId, userType(if any), et al.
This token is read and verified on every page you access if that page requires you to be logged with as a certain type of user.
If authentication fails, you are redirected to a page displaying error asking you to re-login.
What comes out
You are redirected your personal profile page/the page you were accesing to which verifies you with the help of the token.
Additionally, a Digital Certificate may come in picture if you are accessing a banking site or other critically secure site
There are two main ways of performing authentication on the web, and a few less popular ways that are also worth knowing about.
The first is HTTP authentication, as defined by RFC 2617. When you request a protected page, the server responds with a 401 status code, signalling that you aren't permitted to access the resource. In addition to this, it also sends a WWW-Authenticate header, which instructs the browser on how it wants you to authorise yourself. The browser sees this status code and the header, and prompts you for your authentication details. When you enter them, your browser prepares them according to the specific authentication scheme the server specified, and requests the page again, including an Authorization header with the prepared details. The server checks these details against its user database, and either responds with another 401 (wrong details), or the protected page with an accompanying 200 status code to indicate success.
HTTP authentication is one of those ancient features that browsers didn't implement well to begin with and have never really been improved. Because of this, it has become much more popular for web developers to implement authentication themselves using cookies to persist state. In this case, the user is presented with a standard HTML form. When the user enters their credentials into the fields and submits the form, the browser encodes it and sends it to the server in the same way it encodes any normal HTML form. The server checks the credentials, and if they are legitimate, sets a cookie with a randomly-generated ID number, along with a corresponding database/filesystem entry that recognises that ID number as belonging to a particular user.
From this point on, every request the browser makes to the server includes this ID number cookie as an HTTP header. The server recognises the cookie, looks up the ID number, and knows which user you are. When you choose to log out, the server sends a response asking your browser to forget the ID number, at which point you are just another anonymous user.
A less commonly-used option is the use of SSL client certificates. Many people are familiar with the idea of using SSL to identify a server. A cryptographic keypair is generated, signed by a trusted authority, and used to prove that the data being sent originated with the owner of the keypair. What many people aren't aware of though, is that the same can be used by a client to prove its identity to a server. This is less convenient, however, as you need to carry your certificate around with you if you want to use it on more than one machine.
There are variations and lesser-known options available of course, but these are the most prominent ones.
As others have mentioned, login procedures vary depending on implementation, but the basic case (simple web app authentication) uses something like the following pseudocode:
function login(username, password) {
user = db->get_user(username)
if (user == false) {
report_error("Unknown username")
exit
}
if (user->password != hash(password)) {
report_error("Incorrect password")
exit
}
// User authenticated, set session cookie
session->set_data('current_user', user->username)
}
Of course, in most cases, it gets a little more involved than that, but every login function starts its life looking essentially like the above. Now, if we add autologin ("remember me") to the mix, we get something like this:
function login(username, password, remember_me) {
user = db->get_user(username)
if (user == false) {
report_error("Unknown username")
exit
}
if (user->password != hash(password)) {
report_error("Incorrect password")
exit
}
// User authenticated, set session cookie
session->set_data('current_user', user->username)
if (remember_me == true) {
cookie_token = random_string(50)
set_cookie('autologin_cookie', cookie_token, ONE_MONTH)
// Finally, save a hash of the random token in the user table
db->update_user(user, 'autologin_token', hash(cookie_token))
}
}
Plus the function to perform the automatic login if there is a cookie present:
function cookie_login() {
cookie = get_cookie('autologin_cookie')
if (cookie == false) {
return false
}
// Only for demonstration; cookie should always include username as well
user = db->get_user_by_cookie(cookie)
if (user == false) {
// Corrupt cookie data or deleted user
return false
}
// User authenticated, set session cookie
session->set_data('current_user', user->username)
return true
}
NOTE: The above isn't a 'best practices' approach, and it's not very secure. In production code, you would always include a user identifier in the cookie data, use several levels of throttling, store data on failed and successful logins, etc. All of this has been stripped away to make the basic structure of authentication simple to follow.
Anyway, I hope this is what you were looking for, koldfyre. I don't know your background, but if you're unsure of how sessions and cookies work, you should read up on them separately, and if you need more elaborate details, just ask.
P.S.: You may also want to check the question "The Definitive Guide To Website Authentication" for best practice approaches
Look, it's a little hard to give you a lot more information that you already have here; I'm not sure why you want to set a bounty on it. A cookie is just a little bit of named information, and you can put anything you like in it. For a session, you'd want some kind of session ID. There are conventions for that, or you can do it yourself. Whatever you do, when you set the cookie, you leave a little data lying about on the person's browser that is more or less like this:
mydomain.com:
mystuff: this is my stuff, by golly.
When you come back, you retrieve the cookie and get that back.
If you want to see all the details of that protocol, have a look at the Wikipedia article.