In my case I want to test a rest-api protected by certificate-authentication.
I want to use the Paw-App to test this REST-API but I can't find a way to insert/upload my client-certificate and the truststore (jks or pkcs12).
I wonder if it is possible in the Paw-App to enable certificate authentication and how to do that, or if there are any plans to implement that besides OAuth and HTTP-Basic-Auth?
Paw now supports client certificates! :)
https://luckymarmot.com/paw/doc/auth/ssl-client-certificates
Related
I am trying to set up a workflow of authentication to a new kubernetes cluster (Azure AKS) using oauth2-proxy (https://oauth2-proxy.github.io/oauth2-proxy/).
My question is probably pretty dumb, but I am a bit confused.
Is there a way to test a flow like that without having already a valid TLS certificate to use https and a valid registered domain everywhere?
Because for what I see in examples and tutorials everyone is referencing directly with https and registered domains both in Ingress and Oauth2 application (which in my case would be Azure AD App Registration).
There is no way to just have a POC of the tool before buying domains and tls certificates?
Thank you very much!
I would recommend that you start by using proper TLS certificates, because some things don't work over HTTP like they used to do. For example some important cookies will be rejected if set/sent over HTTP.
This is due to the SameSite cookies security property:
see:SameSite cookies
I have configured mutual authentication on an Azure Application Gateway. Currently all client certificates issued by the intermediate CA (as configured on SSL profile) are accepted, but I only want a specific certificate to be granted access, ideally based on the subject of the client certificate. Making changes to the CA that issues the client certificate is not feasible in my case.
Options explored:
Use leaf certificate when configuring SSL profile: app gateway seems to ignore the leaf certificate; all client certificates issued by the intermediate CA are accepted.
Configure a rewrite rule action to pass a server variable (e.g. client_certificate_subject) to backend in a custom request header. This would require changing the backend to interpret the request header, which I’m trying to avoid.
Configure a rewrite rule condition to check server variable (e.g. client_certificate_subject) and conditionally take some action. Ideally the action should set the HTTP response code (without forwarding the request to backend) or rewrite to an error page generated by the app gateway (e.g. HTTP 401 unauthorized / 403 forbidden). Can this be done somehow?
WAF rules don’t seem like a viable option as they don’t have access to server variables
Hoping to find a way of configuring this requirement on the app gateway. Thanks.
I understand that you want to be able to allow specific certificates only based on their subject names etc., to be granted access by the Application Gateway.
You can't use a rewrite rule because in order to "get to" a rule in the first place you have to get through the listener and you can't get through the listener if you can't authenticate with mutual authentication.
At this point, the best way to avoid people from accessing App GW would be to not give the Leaf certificate so they cannot access the same.
Also please note that Application Gateway Mutual Authentication is in preview right now and therefore, it is intended for "Evaluation" and testing, and not production currently. Once it is GA, there will be options to have revocation lists and checks.
Hope this helps. Please do let us know if you have further questions. Thank you!
I'm building an native iOS app, it uses OAuth 2.0/OIDC for authentication and authorisation. The auth server is identity serverver 4.
By going thru documents such as https://www.rfc-editor.org/rfc/rfc8252 I have established that the correct flow to use is "authorisation code" flow even though we own the app, the auth server and the resources.
I also learned that we need to use a secure browser such as SFSafariViewController and that we need to use PKCE and remember to use the "state" key in the request and validate on return.
My problem is validating the jwt on the iOS device. I use https://github.com/kylef/JSONWebToken.swift as suggested on jwt.io
To validate the validity of the jwt we need to check that it was is deed signed by our auth server. The server signs using an async rs256 key and exposes the public key on a endpoint. JSONWebToken.swift does not support rs256 and I have not been able to find any iOS library that does, so how to other people validate jwt on iOS devices? I guess we could swith to HS256 which is supported by JSONWebToken.swift but this is a sync algorithm and would require us to store the key on the device which would not be safe.
How to solve this issue, surely I'm not the only one having it...
You could use the Vapor package at https://github.com/vapor/jwt which does support RS256, but you'll need to fetch the JWK yourself.
I'm working on an app that acts as a SAML service provider. It's written in Rails and uses the omniauth-saml and ruby-saml gems.
Our certificate is about to expire, and we need to create a new one. I'm tasked with verifying that the new one is working. However, none of the IdPs that I've tested with seem to care which certificate I use. When I set them up with the old cert and then switch our app to using the new one they all allow SP-initiated login as if nothing changed.
The app needs to work with all IdPs, and I think that some of them do validate assertion signatures. I need to find an IdP that fails to accept an SP-initiated login assertion when the signature does not match the one that was set up. I've tried Okta, Jumpcloud, and Ping without any luck.
One question is: why don't these IdPs care about the signature for SP-initiated login. But the main question is: how do I find one that does care so that I can test the new cert?
Thanks!
There are two places where your SP's certificate is used: (1) the SP can digitally sign its authentication request to the IdP, and (2) the IdP can encrypt parts of its response with your SP's public key.
For situation (1), if your SP is signing its requests with the new certificate but the IdP responds as before, it could very well be that the IdP is simply ignoring the signature. The IdP might have to be configured to expect and require signed requests before it will fail on an unknown certificate. But note that it is up to the IdP whether it will verify signed requests; for example, according to this post Okta does not verify the signature of signed authentication requests.
For situation (2) use Firefox's SAML tracer or something similar to verify that part of the response from the IdP is encrypted. If not, that would explain why switching to a new certificate that the IdP does not know about continues to work.
It may also be that your SP needs only to know that the person authenticated successfully against the IdP and nothing else, in which case, your SP's certificate is superfluous.
In particular, the Shibboleth IdP can be configured to send back encrypted assertions.
For me, by far the easiest to use and configure IdP or SP test connectors can be found here: https://support.onelogin.com/hc/en-us/articles/202673944-How-to-Use-the-OneLogin-SAML-Test-Connector
There is a list of test connectors that will help you to test different kinds of connections.
Is there any way to locally use OAuth 2.0 without SSL ? I tried to execute it in my localserver. but it says, I need SSL to perfome actions with Oauth 2.0.
Error: it was not possible to open the OAuth access token URL: establishing SSL connections requires the OpenSSL extension enabled
Is there any way to use OAuth 2.0 without SSL ?
Im using PHP Client Library for OAuth 2.0.
The security of OAuth 2.0 is dependent on SSL, without it anyone could see the bearer token that belongs to the user and use it to pretend to be them. However if you need to turn ssl off for debugging purposes and your server is also written in PHP then I would try taking a look at this: http://php.net/manual/en/oauth.disablesslchecks.php
Also SSL is dependent on the server, not the client.