I want to invoke a REST service that is hosted on WAS.
I would like to know how to set the ltpa token in the HTTP Request header while invoking the service using SOAPUI.
Can I set the token in the Cookie field of the header?
If so, what is the format ?
You must set this value in the cookie. My answer works on our WAS 8.5 servers. The cookie value must be:
LtpaToken2=<your token value goes here>
or
LtpaToken=<token here>
NOTE: you must have generated this token in the same realm as your server is running. If you have different realms, dev/test vs. production, your tokens don't work across these realms.
Be sure you have No Authentication selected in SOAPUI so you can validate that the token is working.
Related
I'm currently trying to retrieve a user token from the keycloak token endpoint using a POST request (instead of using one of the designated adapters). I have set up a keycloak realm and added my own machine as a client. In the documentation the Token Endpoint is described as:
/realms/{realm-name}/protocol/openid-connect/token
As far as I have read in the openid specification, I will need to set the body parameter grant_type=authorization_code as well as the parameters code and redirect_uri. I will also need to set the Authorization header, for which I will need a Basic Token.
So far I will get the response:
"error": "unauthorized_client", "error_description":
"INVALID_CREDENTIALS: Invalid client credentials"
Where do I get the Basic Authorization Token from? I expected that I need to provide a username and a password, since the JWT token is what I'm trying to recieve as response. Do I need to set the redirect_url if I just want to request a token?
Keycloak offers more than one way to retrieve a user access token, following the OpenId Connect spec. Here you have the steps to do it for Authorization code flow (the one recommended for web applications) according to the openid connect spec: https://rograce.github.io/openid-connect-documentation/explore_auth_code_flow
Basically, if you're not using any adapter, when detecting a request to some protected resource you should:
Perform a redirection to the keycloak login page (keep in mind keycloak uses the REALM entity, so you'll need to specify it too):
HTTP/1.1 302 Found
Location: https://mykeycloakinstance.org/auth/realms/demo/protocol/openid-connect/auth?
response_type=code
&scope=openid
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
You'll need to keep the state value in the client, as it needs to survive the redirection process:
It is recommended that client’s use this parameter to maintain state
between the request and the callback. Typically, Cross-Site Request
Forgery (CSRF, XSRF) mitigation is done by cryptographically binding
the value of this parameter with a browser cookie.
You don't interact with username/passwords. The keycloak authentication page does. Once the login is successful, it will redirect to your page with a valid code:
HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj
Here you'll need to either check that the state is the one you originally sent (you may need to track it through web session, using cookies) and also to obtain the token using that code. You do a POST to the authorization endpoint with this code:
POST /auth/realms/demo/protocol/openid-connect/auth HTTP/1.1
Host: https://mykeycloakinstance.org
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
This is the flow in summary, I haven't tested the code myself, so use it as an example and don't hesitate to fix it if you consider ;-)
See also:
What are Keycloak's OAuth2 / OpenID Connect endpoints?
In my REST API, user will log in with their username and password for the first time.
When they logged in successfully, we will response with the following format.
{
"token": "0c7f8b870675bc61d92baeef1e274c2d31343736393530373230",
"expire_on": "2016-11-19T18:05:20+0000",
"user_id": 30,
"user": {...}
}
On the subsequent to the REST API, we will just send token in the header to verify the user. token is 52 letters long.
Is it secure enough?
Should I send both token and user_id to verify to secure more?
It depends on how do you generate your token.
If someone can guess how they are generated then it can create a fake one.
If this is a random string that is saved on your server and for each request you check the existence in your server then you are safe.
The best current solution for stateless token is JWT. Take a look at https://jwt.io/
Did you implement your authentication layer? I would suggest having a look at the Oauth2 specification and you are interested in the section when the grant_type is password. If you follow it, it will be safe to return just the access token:
5.1. Successful Response
The authorization server issues an access token and optional
refresh token, and constructs the response by adding the following
parameters to the entity-body of the HTTP response with a 200 (OK)
status code:
access_token
REQUIRED. The access token issued by the authorization server.
token_type
REQUIRED. The type of the token issued as described in
Section 7.1. Value is case insensitive.
expires_in
RECOMMENDED. The lifetime in seconds of the access token. For
example, the value "3600" denotes that the access token will
expire in one hour from the time the response was generated.
If omitted, the authorization server SHOULD provide the
expiration time via other means or document the default value
.
I'm implementing some REST services. All my tests are made using SoapUI.
Recently I decided to adopt JSON Web Token (JWT) for authentication but I could not find any support for this on SoapUI (native install or plugins, nothing).
I found some online generators like http://jwtbuilder.jamiekurtz.com/ but fill all fields, copy/paste on SoapUI again and again for every testcase is not productive at all.
I'm wondering if there is a way to test JWT stuff in SoapUI or if maybe I need another tool. Any advice?
Thanks!
I've found a semi-automatic way to keep a valid JWT token across TestCases without losing too much time, using an external file containing the token.
Have an external tool generating a valid JWT token into a file.
Open your project in SoapUI and add a jwt variable with the value
${=new File('/path/to/token_file.txt').text}
In your requests, reference your variable as a JWT header with the value
${#Project#jwt}
When the token expire, just relaunch the generator script, and SoapUI will automatically load the new token.
SoapUI will call your authentication server and fetch the token, then it will automatically put that token into authorization header (Bearer <token>).
Add new authorization>OAuth 2>Resource owner password credential grant
Then add your username and password into both client and resource section. Finally , put your token end-point as access token url and save the authorization profile to use in other test cases.
I'm trying to get Azure mobile services working with custom authentication. I came across this article:
Get started with custom authentication
and another thread with detailed explanation:
Implement Custom Authentication In Windows Azure Mobile Services.
My question is:
once the token is received after login, does it need to be validated manually similar to this thread ?
I've tried passing the token as Authorization header, but the ServiceUser is always null. (I'm using Fiddler for testing the endpoints)
You do not need to validate the token. Azure Mobile Services will do this for you. For example, it will automatically check if the token has expired, if it has been generated for your particular service (if it's been derived from your Master key), etc.
For example, if you have marked a method with [AuthorizeLevel(AuthorizationLevel.User)] and the token is not valid, AMS will automatically return error response (probably 401 Unauthorized HTTP response). So you do not have to worry about validating the tokens.
In order to use the provided token you have to add the X-ZUMO-AUTH header with the token as value to the request that you send to your service.
I need to implement an authentication scheme for a RESTful architecture. From several articles which I have read include basic Authentication using HTTPs and Session management using Cookie.
However I'm not well understanding the use of cookie. What i understands is that user first sends credentials. The server checks if the credentials are Ok. If yes, the server generates an authorization token and place it in the cookie. Onwards, on each and every request, server checks the validity of the token in the cookie.
But how does the server know that the content of the cookie is valid. Does it stores it somewhere and then it compares it??
The key point here is the authorization token. When generating one and sending back to the client, you store the auth token along with the username in let's say a database. You store the auth token in the cookie. The client on subsequent requests sends you the username and the cookie alongwith which contains the auth token. You verify this token against the supplied username and then perform the action per need.
However, do note that settings cookies makes your webservice call stateful and defeats the purpose of REST.
To achieve authentication/authorization, instead of setting the authorization token in the cookie, send it back as a response value. The client reads the value of auth token and then supplies the same in every REST request as a parameter of request body. Thus, you won't need to set cookies. This you may term as the toned down and simpler version of what is implemented in OAuth based API access.
I'm not an expert, but a good starting point to understand this is the section on Sessions in Hartl's book.
If I'm not mistaken it works as follows:
When the token is created, it uses a formula, e.g. the username and a unique user key (a salt) encrypted together. Both the username and the salt are stored in the database, and the salt is unique to that user. So, as you would do to compare if passwords match, to check the validity of the cookie you recreate the token and compare it to the one in the cookie. If it matches, then the right user is logged in and therefore authorised.
Hope this helps, or at least points you in the right direction :)