I am attempting to abstract the authorization/authentication from my upstream services into Kong API gateway. Previously, I was using express + passport to handle sessions. Whenever a user logs in with their credentials a session would be created with their user info attached to the req object (req.user).
Currently, I am using API keys + session + serverless functions to compare user passwords (using bycrypt lua library) from a file mapped into the Kong container. The client would send an initial login (with username and password) request with an API key to log in, the serverless function would compare the password hashes, if all that passes, the session would get created.
However, my question is, is there a way to store the user info into the session database, so my upstream service can ask for that information to ensure that the session attached to the user logged in is valid at any given time?
Any ideas even if not related to Kong would be appreciated!
When creating a new session on Kong, you can explicitly provide the unique Key used to identify a session (by default created by KONG itself).
When The password checks pass and you are generating a session on Kong you can create your own unique key and use that key while creating the session.
Kong_admin = 'http://localhost:8001'
kong_session = {'key': 'any-unique-combination'}
#any unique combination which you would like to use for identifying the session
user = 'test-user#dummy.com'
#create a session for this dummy user using your key
response = requests.post('%s/consumers/%s/jwt' % (Kong_admin, user),data=kong_session)
#Once the session is created you can find it using
resp = requests.get('%s/consumers/%s/jwt/any-unique-combination' % (Kong_admin, user))
# you can use this key in your token payload so your upstream service can decrypt the
# payload and get this key and you can store this key in your database mapped with
# user during session creation.
# with this you ll be able to decrypt any session payload , get a key and then query
# it on database at any point of time
Related
I'm trying to encrypt my sensitive data for an application. For the key generation part, I'm using crypto/pbkdf2. I'm generating the encryption key on the fly based on the user supplied password. When a user is created, that's when I'm encrypting the corresponding data of the user with the user's supplied password. However, whenever that particular user tries to access a resource, I've to decrypt the data before showing it to the user. Where do I get the password from, everytime an endpoint is called by that user to access a resource?
Note: I'm storing the hashed password of the user in the database schema, also I don't want to store the encryption password anywhere!
The typical solution to this is called token-based authentication (or in OAuth terms, Resource Owner Password Credential Flow).
Create a "login" endpoint that will derive the encryption key from the supplied username/password and exchange it for a (time-limited) "access token", storing it in a key-value store with TTL support (e.g. etcd, Redis).
Then each subsequent request will need to supply the access token (e.g. in the Authorization header), which is then used to retrieve the encryption key from the key-value store.
So i read about how authentication is done using JWT, where we basically verify if the token is valid using a private key (assuming RSA is the algortihm). And if the token is valid, then the user is considered authenticated. And I also read about session authentication where we check if the user supplied session id (through cookie), exist in the session store (assuming mysql / redis is used to store session). If it exist, then the user is considered authenticated.
But how do we use JWT and session for authorization ? Lets consider an action such as GET invoice , whereby a user can only view the invoice that he owns.
If we consider the user is already authenticated,
how do we check if the user is authorized if we are using JWT?
And how do we do it for session ?
You are probably confusing the things. One of the benefits using JWT is to avoid maintaining sessions which is big bottle neck in scaling.
JWT (Json Web Token) carry all the information that would require it to get authenticated, you don't need to maintain the session. Every single HTTP request to server will carry JWT that would contain necessary user claims including the signature. On server you will validate the signature to verify if the token is valid or not. You can verify the token without maintaining any session and there are number of ways to do it.
Since JWT is essentially a Json object (Header, Body , Signature) , you can put in claims (emails, roles, profile etc) in JWT body. Once you verify the token , you can extract the claims including any roles and check if user is authorized to access the resource.
You must look into Open ID Connect and Tokens here
I have the following scenario that I am curious if it is possible to implement. I need to use SSO and more specifically OneLogin to authenticate the user via custom UI from my Java standalone application. I know this can be done via Create Session Login Token and then Create session via token One Login API calls. With some parsing I can get the session cookie out of the last call and store it.
Now I need to programmatically hit the API server, which is to be build still and this server somehow needs to validate the session cookie that I am going to send along with request. The key word "Programatically" as in there will be no browser
OneLogin doesn't provide SDK to validate existing session cookie => it would be nice if I could, based on session cookie find out if it is still valid and what is the user name used for this session. If session is invalid API server would return unauthorized.
Is this even possible? Or is it possible in some other way?
Basically One Login is already used in our ecosystem and I have to continue using it
The app that will log user in and get the session cookie may not be the one calling the API server. This could be another java application that would receive the session
I guess what I am looking for is Validate Session equivalent from Open ID Connect API in general API
The session_token that is returned via that API has a short expiry is only intended to be used for making the Create Session request which returns session cookies.
It sounds like OpenId Connect might be the best option for this use case. If you have user credentials then you could use the Resource Owner Password Grant flow to authenticate the user and obtain an id_token.
The id_token is a JWT containing user details can then be verified for authenticity by checking its signature, audience and expiry claims. It can also hold other custom information about the user that may be used by your backend application.
I want to simulate the password reset service for service now users from an external application and I have installed Password Reset - Orchestration Add-on plugin on my servicenow developer instance. Along with this I can see a list of Pwd Reset APIs on my REST explorer (e.g pwd_init, pwd_verify, etc). I went through the documentation available on this documentation page but I'm at a loss to understand what the request payload would be like if I'm trying to call these APIs from an external service like Postman. I wanted something similar this api documentation.
Can anyone help me with this?
Use the Table APIs to do this.
In order to reset a user's password, you basically want to update the user_password field of the user record from sys_user table.
Method: PUT/PATCH
http://<instance>/api/now/table/{tableName}/{sys_id}
here tableName will be sys_user and sys_id will be the sys_id of the user's record in sys_user table.
The body of the API request should be something like this:
{
"user_password": "resetpasswordtext"
}
Bear in mind that this will reset the user's password but the new password will not be "resetpasswordtext". So the user will not be able to login using "resetpasswordtext".
To actually set the password for a user via API, same table API as above can be used. But in order to store the password properly encrypted in the database, below query parameter should be added in the request URL to set the password.
sysparm_input_display_value=true
So the API call will be
Method: PUT/PATCH
http://<instance>/api/now/table/{tableName}/{sys_id}?sysparm_input_display_value=true
BODY: {
"user_password": "newpassword"
}
Now the text "newpassword" can be used by the user to login to the instance.
hope it helps in your use case.
so, my use case did not involve using the Password reset API, but for those of you interested in generating a new password externally, then making an api call to set that as the new password for that user, then here is acode sample that is based on Milind's answer above:
Python3
def change_password_snow(user, pwd, new_pwd, snow_url, sys_id):
# Set the request parameters
url = snow_url + sys_id
# Set proper headers
headers = {"Content-Type":"application/xml","Accept":"application/json"}
# Set query params
params = {"sysparm_input_display_value": "true", "sysparm_fields": "user_password"}
# Do the HTTP request
response = requests.patch(url, auth=(user, pwd), headers=headers, params=params, data=f"<request><entry><user_password>{new_pwd}</user_password></entry></request>")
return response
Setup on ServiceNow
For this to work, the user you are authenticating with in ServiceNow needs to have Admin privileges.
Either that, or modify the sys_user.user_password ACLs to allow non admin users to read and write to that field if they have a role that you select. For my use case, I created a custom role and attached it to that user.
Found myself opening a couple of functions for access to users with invalid session tokens. The only way I could find to do that is to intercept the request using a bodyParser before Parse gets the request and removing sessionToken from the request.
Now trying to do a better job managing authorization to all functions - My question are:
can I relax the requirement that if a sessionToken is included it must be valid in any other way? Is session token validation done using a default validationHandler that can be replaced or is that done elsewhere?
to control access to cloud functions, is there anything like ACL roles? does cloud function's "validationHandler" accept only param? or can I inspect the user object as well?
Yes. In parse-server you can make sure that the sessions are valid because if you will try to run any CRUD operation with invalid session you will get http 403 error that your session is not valid or expired. You can control on the "Length" of your session by changing the sessionLength property in your parse-server app. The default is 1 year
There is no control access to cloud functions but you can check if a logged in user trigger this function by checking if the request.user is not undefined. Cloud functions can get only params in key-value pairs and those params cannot be Parse Objects. if you want to send ParseObject you can send the objectId of the parse object and then query for it in cloud code to get the full object. You can always access the user context in request.user (only if cloud code was triggered by the user). If you still want to "protect" your cloud code you can check if the calling user have a Role by query the Role DB and check if the user is contained there.