I added an HTTP Authorization Manager to JMeter, an HTTP Request Default and an HTTP Proxy Server.
I configured my HTTP Authorization Manager control Panel as:
Base URL: http://www.gmail.com
Username: abc
Password: xxxxxxx
But I am getting error in internet explorer when I open http://gmail.com
Error:
There is a problem with this website's security certificate.
The security certificate presented by this website was not issued by a trusted certificate authority. The security certificate presented by this website was issued for a different website's address.
Security certificate problems may indicate an attempt to fool you or
intercept any data you send to the server.
Can anybody tell me what I am missing or doing wrong?
Thanks in advance.
What are you trying to achieve? Are you trying to log in to gmail to read emails via Jmeter?
If so, it's not as easy as pointing to the gmail URL and using BASIC authentication. You could get an idea of what's involved by using BadBoy to record the actions you want to do and then export it to Jmeter.
That said, this is not a good approach.
I'd be looking at using the POP3 interface - trying to simulate a browser with Jmeter for a site like gmail which changes every day could be very difficult. It should be possible to write a Java POP3 client (or better yet, find an open source one) and call it from your Jmeter script.
Related
There are multiple requests being passed in signing in of the application since its using Sitefinity - Azure AD B2C Authentication and there are some values being passed in each requests such as nonce, state properties, id token etc. The workflow is quite complicated when having a peek into the values/token being passed across the requests of login. Though I have created/tried with all the values that are getting as the response of previous requests, still the login is not happening. Also, I went through some documents of B2C authentication with Sitefinity and its architecture and I got to know that the token being generated by the Sitefinity is an internal process and the response of that token cannot be fetched from a previous response/ client side.
Workarounds that I did:
Integrated selenium into Jmeter and automated the login scenarios and stored the cookie generated. Then used these cookie and token in following internal requests- This approach worked fine.
Hardcoded a live cookie in Cookie Manager and send the internal requests - This also worked fine.
I am wondering if there is any other possibilities in logging in because the above two methods are not reliable in long run. Anyone have idea about generating the token id locally and pass that to JMeter. for example creating a .exe file which generates the Sitefinity token.With this we will be able to pass or execute the .exe file in OS Process Sampler in Jmeter and fetching the token from its response.
Or
Any other approach?
I assume you are using the OpenIdConnect authentication provider that is built into Sitefinity?
So, basically when a user clicks on the Login button, he is being redirected to:
/login/LoginExternalProvider/OpenIdConnect/
Here Sitefinity replies with a redirection to:
/Sitefinity/Authenticate/OpenID/connect/authorize?client_id=sitefinity&....
which in turn redirects to
/Sitefinity/Authenticate/OpenID/login?signin=....
and this finally redirects to the external authentication provider.
(yeah, it is a complex workflow).
So, if you try to load test only the first request (/login/LoginExternalProvider/OpenIdConnect/) - wouldn't it then follow the redirect responses automatically (sorry, not familiar with jmeter)?
Those responses contain the correct cookies that Sitefinity has created, etc.
As per Sitefinity documentation:
Sitefinity CMS uses claims authentication, implemented on top of IdentityServer3, certified by OpenID Foundation. It allows implementing single sign-on and access control for modern web applications and APIs. It uses OAuth2 and OpenID Connect protocols.
Standardized authentication, based on OpenID Connect with JWT, certified IdentityServer3.
Given you're capable of logging in using your browser - you can replicate the same requests using JMeter's HTTP Request samplers, it's just a matter of correlation - the process of extracting the dynamic data from the responses and using them in the next requests.
You can refer OpenID Connect - How to Load Test with JMeter article for example JMeter script implementation
I'm trying to setup Keycloak on a Linux server in order to prepare an OAuth2 server to make linking account available for my Alexa Skill.
My problem is this:
After a succesfull login, keycloak redirects the request to an Amazon server with this link:
https://skills-store.amazon.co.uk/api/skill/link/M3FC1DYEAOGRP4?code=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..XDTXJ_GzoEs06ELehNLRhA.njBRnNSp0-nJN1sz9-jt-x6dWVdfIANQVfoKJsiJAYry3yW9fSNS46H5Daji-C8oY-lPQSTl_oiPbWOLmsfN5J5y5BOxlWPPBLkudyyNQj1bznmiz_flabn0JiTsqcy4V5cb07E0wgO4GBYDPh1JxMBzv1jY-8zHJFjWZ_aHJ_HN2ADSJywksp9TQlfsVFM2DoPFr-3hzerjHxJmje8AHhh3fl_hm1L8YLwZ81JxAyYbRX06vL4dDC1We0fJ1Gau.zXXS_02gcqqy7GAMt4HPNA
&state=A2SAAEAEKGYeJWc5-LPQwpOBdADVIkB4LaRW5zez4dbd6yYW8ZZNyXA_ujSlkPoxLvi-QzwydlEcAgR0Y70aJ7DuNr-vTbbowBpZzCbBzk2wfaHOa980SNhuckEERT6slAVbZ5eVKd7sLaVQ-K3qwHwUzSRRVa32Wnu__i9vMrqBhZE6rBqZjmkKvh3BwKGk2EloEc2sg64b4TQyFm8qsUmfGowSL2cKu4jYwq-utIoczJXEXg6w1Dh5wUYc3hH6b505z9Xhlw3PL7BatTRpCzX7VNq9D1gX60xWkicl2x3q5HTmSV2rviYgA1s_bEGYrv95mYxi57S1Zi4v3xGmNVn4Yt-YGJIVXRPa6wKalHedIOTDEYTunmHsmVI_EoMhx7ReJh9Ur-k1c6D3o6ul4Xmk7ue1KuU3t69aS1CEWopFTjiGHticFYOuYogvbScCgbt8Gg21o9PsL-EL0jxuH4-Zc7gjdBL_pDZCAMlVk6IOMLkMW2GQTp8rzvT7Bi-ATVvINWlS5AesggTpJH7Itm-HJsRib8DmQTd5_RL4VR7l25nLdzDdx8FA4kpESH2Rfr21hE9UM9NcBRG4T7uysvhvDzlKFMa
I understood that my problem is in the &code= format.
Amazon is waiting for application secret (36 length string) instead it is encrypted by default in Keycloak.
Is there a way to edit this behavior in Keycloak admin console?
Thank you
Edit:
Keycloak version is 4.0.0 Final standalone
To follow the Keycloak client configuration images:
That's the Amazon Skill configuration for account linking:
And these are the Keycloak client configurations:
In the end, that's the issue:
When i click on account linking link from the skill I correctly go to the login page
but then, skill is never been actived:
The study of this issue brought me to UPS Skill and using Chrome developer console I noticed that the code parameter gave to pitangui url is a 36 digit string.
So, at this point I think that Amazon requires the plain secret as code even if I'm not certain of this.
So my question is if there's a way to edit Keycloak behavior without changing Keyclok source code.
Thank you
How Firebase domain whitelisting works behind the scene to make it foolproof?
To be clear, I'm not trying to configure my domain in Firebase console(Which I understand how to do), but instead, trying to build some similar source domain validation in my server side - API code. What web standards Firebase uses to make sure only authorized domains make API call as the API token is public.
What if someone uses non-browser HTTP client with source domain headers faked with the API token of my app? I assume Firebase would've thought about such case and its covered. Trying to understand the how its foolproof.
My guess would be that it is not fool-proof, but limits the use cases in certain situations.
You could use such a whitelisted domain in the CORS related headers, this would prevent certain actions from modern browsers.
The whitelisted domains can also used with authentication to make sure the redirect after login is to your domain.
Theoretically you could go and check the Referer header, but a lot of browsers do not supply it for security / privacy purposes so that would be a bad option.
As for firebase, since it is quite hard to use firebase without the library, the library can just supply the current url to the server and prevent any action from unlisted domains. This is by no means fool-proof.
What if someone uses non-browser HTTP client with source domain headers faked with the API token of my app? I assume Firebase would've thought about such case and its covered.
I think your assumption is wrong. Clients are insecure and any request can be faked. Eventually it's a packet that is sent to a server and if you control the sender you control the contents of the packet.
If we monitored the connection between the client and Firebase we can figure out a way to perform the same tasks from another (out of browser) process.
TLS. If you look at the IETF's documentation Handshake Protocol Overview :
When a TLS client and server first start communicating, they agree on
a protocol version, select cryptographic algorithms, optionally
authenticate each other, and use public-key encryption techniques to
generate shared secrets.
So, I think this is the mechanism used for domain whitelisting. Regarding faking HTTP headers, Firebase does not accept HTTP, only HTTPS (TLS).
I have Android app that talks to .net 2 webservice (IIS7) using http get and managed to make it run on https using self-signed server certificate (but not requiring client certificate).
I see all http traffic is encrypted and it looks secure.
Now what options would I have on how to authenticate client? For example, I like to block webservice access from internet explorer on PC.
Client-authenticated TLS handshake described here would be a way to go?
Then how can I accomplish that? Some advice or example will be appreciated.
Well, given that each user should authenticate anyhow, you probably want to setup some sort of per-user authentication strategy for a variety of reasons. First, given this might be a widely distributed app, having a single "gold master" authentication certificate or credentials will ultimately fail as someone will hack it -- either grabbing the cert or grabbing the account. And then what do you do? Second, its not particularly hard to handle. You can easily use ASP.NET membership to back it, and then take the credentials a number of ways depending on the nature of the service. Third, it is alot easier to manage than client certificates.
I’m developing an Intranet application and I want to make a secure authentication.
One approach can be use “https”. The problem is that the server doesn’t have a trusted certificate, therefore is a bit annoying for the client because the browser doesn’t trust in the certificate and complaints with a scary message.
Using http will compromise the user password but it can be combined with “Digest access authentication”
What do you think?
As of November 2015 you can't buy certificates for internal domains so as far as I know the only option is to pre-install the certificates on clients. Not a great solution.
Another possability if you want to keep your internal domains private is to create a public domain: mycompany.com, and then run your own DNS server internally that resolves your internal domains: accounting.internal.mycompany.com, hr.internal.mycompany.com and so on. Then I believe you can use a wildcard certificate for mycompany.com. I haven't tested this solution.
These are (y)our options:
If you have mostly Windows hosts, you can Distribute Certificates
to Client Computers by Using Group Policy | Microsoft
Docs
and use your own self-signed certificate in this way.
Non windows users or Windows machines not in the domain will have to
go through the hoops and warnings of either installing the
certificate properly manuallly or allowing the self-signed certificate.
A bad user experience.
You use a proper domain name, a real certificate and a messy DNS
configuration where www.mycompany.com resolves to an external site,
but wiki.mycompany.com is an internal site (But please, please don't put the internal
address for wiki.mycompany.com in an externally visible DNS record!)
You don't use HTTPS at all and use HTTP. Possibly by inventing your
own security for login pages (Yikes!)
They all suck.
Especially if you want to distribute an enterprise-ready onsite app, and you don't know the customer's network and DNS configuration beforehand.
Purchase a domain and trusted certificate? They are really not that expensive anymore if you shop around.
Having said that, digest access authentication is reasonably safe for authentication. Using http rather than https, all of the information you send across the wire will be plain text even if the password is not. Anyone that can plug a laptop in to your intranet running an application such as WireShark can view all of the information sent back and forth. If you care about that information not being compromised, http will not meet your needs.
You have these options:
Purchase a trusted certificate.
Or, generate your own root certificate, install it in browsers on all intranet computers (you should be able to do it since it's intranet), generate your own server certificate signed with your own root certificate. This is actually what companies often do.
Note: Digest access authentication is not helpful if you want to have form authentication (a HTML form with user, password, login page using the visual style of your app, nicer wrong-password error reporting, possibly additional features such as "remember me" or "forgot password").
If you need it to be a fully secure, you should purchase the SSL certificate.
From the wiki link you provided:
Disadvantages
Digest access authentication is intended as a security trade-off; it is intended to replace unencrypted HTTP Basic access authentication which is extremely weak. However it is not intended to replace strong authentication protocols, such as Public key or Kerberos authentication.
I think there's your answer :)