JWT verification module for Apache2 compatible with CloudFlare - apache2

I am planning to set up a CloudFlare proxy in front of my web service and use mTLS for authentication (see https://community.cloudflare.com/t/mtls-user-propagation/371991). Ths mTLS terminations is done by CloudFlare. What will arrive at my web server is an HTTP header called Cf-Access-Jwt-Assertion, containing a JSON Web Token (example can be found in above link as well) with claims.
Is there a way to configure Apache2 to verify this JSON Web Token for me so that my application does not have to?
This module would need to download through a given URL the public key of the JWT for verification, and would need to be configurable to verify certain claims in the JWT, e.g. the aud field or others.
Note: I am aware that a solution for HA Proxy exists, but I am explicitly looking for one for Apache2.

Related

Azure AD Registered App Web URI Resolution in HashiCorp Vault

As part of our Azure AD and HashiCorp Vault OIDC single sign-on implementation, I have registered an application in our corporate Azure AD and provided a couple of allowed redirect URIs in my Terraform configuration that are along the lines of the following:
allowed_redirect_uris="http://localhost:8250/oidc/callback"
allowed_redirect_uris="https://{hostname.domain}:8200/ui/vault/auth/oidc/oidc/callback"
The terraform configuration is provisioned via a GitLab CI/CD pipeline and manages to deploy successfully. However, when I then attempt to login into Vault via the UI (as shown below), I get a Microsoft Sign in error message pop-up which includes the following:
AADSTS50011: The redirect URI 'https://{hostname.domain}/ui/vault/auth/oidc/oidc/callback specified in the request does not match the redirect URIs configured for the application '{Azure Tenant Id}'. Make sure the redirect..............
Note: The URL displayed in the error message is somehow missing the port number 8200 which is definitely included in our Azure AD registered app redirect uri configuration.
I have even tried stripping out this same port number from my Terraform code and redeployed, all in an attempt to keep it consistent with the expected URI given in the error message. Yet still, this has failed to yield the desired result and I keep getting the same error.
Any idea what could be the issue?
Found one of the similar issue , please check if that could help .
According to discussion in similar github hashicorp vault issues
Vault’s OIDC provider should validate loopback IP redirect URIs
according to rfc8252 section-7.3 : The authorization server MUST
allow any port to be specified at the time of the request for loopback
IP redirect URIs, to accommodate clients that obtain an available
ephemeral port from the operating system at the time of the request.
This Feat/OIDC loopback redirect dynamic by paladin-devops hashicorp/vault · GitHub
discusses to add checks on OIDC provider to allow for redirect URI to have a dynamic port in the redirect URI if the loopback address is included in the OIDC client
References:
OIDC Provider Loopback Interface Redirection Issue- hashicorp vault (github)
hashicorp vault/OIDC loopback redirect dynamic by paladin-devops
GitHub

Pub/sub push subscription to an endpoint API URL

Since it is mandatory to register non app-engine endpoints as mentioned here,I can't register my endpoint and it shows the error: Invalid property URL; please specify a site or directory URL, not a page URL.Screenshot here
What can be the alternative?
Make sure you have:
A HTTPS server.
A valid SSL certificate.
Register the endpoint domain with the GCP project.
Register the https:// version of your site URL.
Configuring HTTP Endpoints
You need a publicly accessible HTTPS server to handle POST requests in order to receive push messages. The server must present a valid SSL certificate signed by a certificate authority and routable by DNS. You also need to validate that you own the domain (or have equivalent access to the endpoint). Finally, you must register the endpoint domain with the GCP project. Note that these steps are considerably simplified on App Engine, where SSL certificates are provided and verification requirements can be relaxed.
Step 1: Verify you have access to the domain
Complete the site verification process using Search Console. Be sure to register the https:// version of your site URL. For more details, see the site verification help documentation.

App Engine access service(s) with custom domain and HTTPS

I have a GAE app set up to use a custom domain, let's call it mycustomdomain. This naked domain is working fine over HTTP and HTTPS. I also have a service called api, it can be accessed successfully by going to http://api.mycustomdomain.com (custom domain convention).
However, I can't access the api service over HTTPS. I uploaded a SSL for mycustomdomain.com, but I got an error (site can't be reached) for trying to accessing the api service over HTTPS. My question is do I need to purchase the wildcard.mycustomdomain.com SSL in order to access the api service over HTTPS? I don't have much experience dealing with SSL certs and GAE custom domain, so any help would be greatly appreciated. Thank you!
Edit: updated information for GCP Console configurations.
My app setup in the Console contains the following:
Services: default, api
Custom domain setup: mycustomdomain.com
SSL uploaded: ultrahdlivewallpaper.com (NOT the wildcard version), api.ultrahdlivewallpaper.com (unable to be enabled for custom domain, none matching)
More detail: The problem is when I map both ultrahdlivewallpapers.com and api.ultrahdlivewallpapers.com, they are both mapped to the default service. I want api. to point to the API service. If I only map ultrahdlivewallpapers.com, that allows me to access api service at the api subdomain, but then the api SSL can't be applied to api. subdomain because it's not listed as a subdomain.
07/24/17 Update: I believe this is a limitation with the App Engine Settings after trying out several scenarios via GAE Console. We have a custom domain set up for ultrahdlivewallpapers.com and enabled the SSL cert for this domain. The domain is pointing to the default service. We have a second service set up called API. Google's routing rules for any service set up is via HTTP:// service-id.custom-domain, which in our case is api.ultrahdlivewallpapers.com. However, when I upload the SSL for the api subdomain, Console couldn't find matching domains because the api subdomain is not specified via the Console. Now if I set up api.ultrahdlivewallpapers.com as a custom domain, I'm able to enable the SSL for api subdomain. Problem then becomes api subdomain is now pointing to the default service instead of the api service. If I remove the api mapping, I'm able to browse to the api service again, but no HTTPS! I don't believe there is a way to get this set up correctly without a wildcard SSL enabled for all subdomains. Please let me know if I'm missing anything. I have tried everything I can think of via the Console. Thanks.
You don't necessarily need a "wildcard" cert, per se. But, you do need to get a cert that covers all the subdomains. For example:
mycustomdomain.com
www.mycustomdomain.com
api.mycustomdomain.com
It's a standard solution, and not difficult to do. Certbot (Let's Encrypt) makes it easy.
If you choose to get a wildcard certificate installation is pretty straight forward:
You upload the certificate in the developer console (in App Engine -> Settings -> SSL Certificates -> Upload a new certificate). May require a bit of effort, see also Google App Engine SSL with Let's Encrypt "could not be inserted".
Once it's visible in the certificate table you can click on its name and you'll end up in the certificate edit screen where you can select which custom (sub)domains it applies to (from the list of all custom domains mapped in the app), looks like this:
Note: these are the corresponding custom domain mappings:
If you have another app (under the same admin account) which is also mapped to subdomains of the same domain you can activate the certificate on it as well in a similar manner (the console automatically shows the certificate in the list when you switch apps, no need to upload it again).

SAML ACS Assertion Consumer Service protocol

I am trying to authenticate a ruby on rails app through SAML with Azure Active Directory.
In the AD settings it is only allowing https not http URLs as the "reply url" AKA the ACS or Assertion Consumer Service.
My question is does the ACS url have to be over https, if so, is there a way to develop with an app on localhost?
For this specific issue, I always use tunnelling app https://ngrok.com/
Install and run
ngrok http 3000
Then you can use https
ADFS is somewhat specific and sometimes does not implement the SAMLv2 spec correctly (i.e. the IdP meta data has not been meta data schema compliant).
The ACS endpoint need not be secured on the transport layer, although SAMLv2 recommends this.
However as you might use a so called "frontchannel binding" (HTTP POST or HTTP redirect binding), why do you bother? The browser is doing the communiation, not the app. Only if you use a 'backchannel binding', like Artifact binding the App (acting as the SP) needs to talk to the IdP (not with the ACS in this case, but the "ArtifactResolutionService")

Angular JS SPA using LDAP authentication

I'm writing an AngularJS SPA application which calls Rest full web service. Back-end is being written on JAX-RS, deployed on Tomcat 7. I'm using HTTPS, SSL for transferring data from SPA to JAX-RS
requirements
I have to make LDAP authentication. (I will send username & password to web service and it should make authentication)
I have to do user's session management (because, when authenticated user sends request to web service, user doesn't have to authenticate again)
problems
I think there are two options for doing LDAP authentication:
Make LDAP authentication using core java http://docs.oracle.com/javase/jndi/tutorial/ldap/security/ldap.html
Use Spring security (I'm not familiar with it and not sure if it's possible. I think I should send username & password to rest service. Rest service will have spring security library injected and it'll be possible to use authentication functionality. Am I right?)
Manage user sessions. Once user is authenticated, it should be saved somewhere, so that user can do operations until its logon is not expired.
How can I do it?
Which way should I choose? How should I make LDAP authenticating and session management?
Can anyone give any suggestion or example links?
So,
LDAP Authentication using JNDI works just fine, you could also use the neat UnboundID LDAP Java API. A simple LDAP Bind example can be found here: https://code.google.com/p/ldap-sample-code/source/browse/trunk/src/main/java/samplecode/bind/SimpleBindExample.java .
Note also that you could use a Node.JS module as your backend, the Passport.JS Authentication framework for example, provides lots of features/capabilities relative to authentication and Federation (i.e., do things like 'Login with Google', etc...). See: passportjs.org.
On the Angular/frontend side,your best bet is to use a JWT token. It's all explained in detail with examples here: http://code.tutsplus.com/tutorials/token-based-authentication-with-angularjs-nodejs--cms-22543.
In essence:
your backend Authentication REST should return a JWT Token in the response, once the user successfully binds to LDAP. This Token would contain some user data, and should be encrypted (see link above).
Your Angular App should set that token as a cookie on the client Browser ("set-cookie" response header) upon successful login (so in the Controller of your Login view).
The Client will then present that cookie/JWT Token on every request it makes to your app.
Your app will then need to validate the token presented on every request (in the controller of your SPA). You may also want to add the user authentication data to your $scope so you can use it in your view.
Hope it helps...

Resources