STIG Manager (non-local) over HTTP and UN/PW, is it possible?

[danielcornwell615]

Greetings! I'm currently setting up a test-bed instance of STIG Manager to see if it's feasible for our organization to switch over.
I am able to successfully use the Sample Orchestration (localhost) that NUWCDIVNPT so graciously provided with no issues.
I figured that I could replace localhost to the IP or FQDN of our server hosting the containers to access it across the network, but apparently, it's not that simple. I get a message on the landing page that states:
"The app is not executing in a secure context and cannot continue. To be considered secure, resources that are not local must be served over HTTPS:// URLs."
I see that you also have a sample orchestration that includes CAC Authentication (something we don't need/want) and HTTPS.
My question is this: Is the app designed to allow non-secure HTTP non-local access via UN/PW? Or will it only work non-local over HTTPS?
If the latter of those two is true, then would I be moving in the right direction to use a NGINX proxy and self-signed certs and just comment out the SPI envvars to negate the CAC Auth?

I know you guys are hesitant to provide any environmentally specific instructions (rightfully so), I just want to make sure I'm spending my time moving in the right direction. Current and end-state goals are below:

Current test-bed goal: Non-Local (accessible across network, HTTP) instance with no persistent storage, no-CAC auth... just Un/Pw.

End-State: Non-Local (accessible across network, HTTPs) instance with persistent data storage, no-CAC auth... just Un/Pw

Tech Set used: Rhel 8 Enterprise VM w/ podman/podman-compose

Thank you for your time,

Daniel

[csmig]

Greetings to you, Daniel! The tldr; answer is yes, you are moving in the right direction by aiming for an HTTPS deployment without CAC and persistent storage.

I'll also take the opportunity to explain why the HTTPS requirement is there and where it applies. The API service does not require HTTPS and all endpoints will work just fine over HTTP. It is the first-party web app offered by the project that has the requirement to be served from a secure context (localhost or HTTPS). That's because we use browser APIs that require a secure context, including a service worker (which can actually be bypassed but results in a reduced feature set) and FIPS 140-3 compliant hash functions (which we cannot make optional).

And as you've already noticed, CAC is not a requirement at all just a popular deployment option.

--Carl

[csmig]

Another thought, since you say you have a short-term goal of a test-bed with non-local HTTP. If you have a small number of clients, it might be feasible to configure SSH reverse tunneling on each of them. Each client could establish an SSH session with the container host like so:

ssh -R <client-local-port>:localhost:<container-exposed-port> <user>@<container-host>

From the remote client's browser, navigate to http://localhost:<client-local-port> and you should be served the web app in a secure context.

You may need to jigger the SSH client and server configs to enable reverse tunneling since it is often disabled because of potential misuse.

Just a thought, I do this in my local dev network now and then.

[danielcornwell615]

Quick question... when comparing the localhost and the CAC/Nginx orchestration examples, I noticed the ports listing/mapping is completely different. For example. the yaml for the example with cac auth only has port 443 listed, and has no ports specified for SQL or the API section. Where as the localhost version has port mappings for each service e.g. 51000:3306, 54000:54000. Is this because all traffic will only flow through 443 now and there's no need for the other ports? Also, the auth portion seems to be using a different image uay.io/keycloak/keycloak:19.0.2 instead of nuwcdivnpt/stig-manager-auth. Please forgive my ignorance, just trying to work things out in my head.

[csmig]

Is this because all traffic will only flow through 443 now and there's no need for the other ports?

Yes, indeed! That orchestration only exposes 443 from nginx on the frontside and the routing to the other services happens on the backside.

the auth portion seems to be using a different image uay.io/keycloak/keycloak:19.0.2 instead of nuwcdivnpt/stig-manager-auth

nuwcdivnpt/stig-manager-auth is a custom image built from a base KC image, with pre-populated user accounts for quick demo purposes. The CAC example orchestration uses the base KC image directly.

[danielcornwell615]

Thanks Carl! I appreciate your reply and the insightful info on the web app requirements.

We're going to push forward with the end-state goal and get the Nginx and CA certs squared away.

Take care,

Daniel

[hearts1137]

Did you ever get a working proof of concept that is HTTPS accessible over the network and does not require CAC authentication? We are also attempting to standup a STIGManager instance in AWS that cannot use CAC auth and hitting a lot or road blocks. I wish there was a better guide for a simple HTTPS deployment that isn't bound to just localhost. Thanks

[cd-rite]

Hi @danielcornwell615 @hearts1137 @hasib-haque @petertirrell
It sounds like several people are trying to deploy STIGMan with username/password and/or on AWS. This is absolutely feasible, but specific configuration of elements outside of the scope of our app is not really something we can offer too much support for. Hopefully you'll be able to help each other as you make progress.

That said we will help whenever we can! It sounds like many of you are getting hung up on https. Our app expects https to be performed on its behalf by the proxy. This will most likely require proxy configuration similar to our sample orchestration, and that you provision your own certificates acceptable by our organization. (A certificate issue is the most likely reason for any "secure context" type messages you might see).

One user has contributed their configuration for a username/password Docker-compose orchestration here, in the "Community Solutions" section of the STIGMan Orchestration repo readme:
https://github.com/NUWCDIVNPT/stigman-orchestration?tab=readme-ov-file#community-solutions

In theory, you could just run this entire orchestration on a VM in AWS, rather than using their various container services, etc. with proper proxy/ingress configuration, certs, , etc. but that might not be suitable for production.

You also may be using your cloud provider's OIDC provider, rather than Keycloak. In that case, the end goal remains the same, create an access token that meets our requirements here: https://stig-manager.readthedocs.io/en/latest/installation-and-setup/authentication.html#json-web-token-jwt-requirements

When you settle on a working configuration for AWS, or any other solution you think is useful, it would be great if you could help out the STIGMan community by offering a sanitized version of your deployment files on a public repo like GitHub.
We would gladly accept a Pull Request to our STIGMan Orchestration repo with a change to our ReadMe.md file that contains a link to your repo.

We will also clarify our Documentation where applicable as the conversation evolves.

[hearts1137]

Hi @cd-rite, thanks for the write up. The community repo is not a valid or usable repo out the box. Specifically the image locations; for example https://github.com/jeremyatourville/stigman-orchestration/blob/2807e4ba935e5ee6e02580dd131ccc5b5c488769/docker-compose.yml#L9 "image: gsil-docker1.idm.example.org:5000/nginx:1.23.1"

I have tried many combinations of the community repo with the official repo to get the system to deploy to something that isn't the localhost. I don't really know what I'm doing.

My use case it to host stigman in an offline cloud environment, think IL6, and provide my own DISA NPE certificate for the web site and authenticate with username and password. CAC/Token authentication is just not an option due to the nature of our system and how it is accessed.

With all that being said, would it be possible to advise on how to enable BOTH kinds of auth into keycloak? I know that keycloak can support both user/pass and DoD issued credentials like CAC and SIPR token. See attached screenshots of a system I use that can handle user/pass, user RSA+PIN and DoD CAC.

Any help would be appreciated. I am an ISSE and not good at all with containers or keycloak. It's like greek to me and I could use all the help I can get. Running it locally on a Windows 10 laptop with internet access is a breeze and the tool is amazing. But we need it in our production environment where CAC auth and internet access is not available. I can download the containers and the repo data, just stuck on configuring keycloak to use user/pass or bypass CAC auth. I can't exactly bring in my dev laptop into the vault to show my ISSM all the cool stuff I've been working on and the amazing answer files I've created!

[cd-rite]

Hi @hearts1137
I've pushed a branch here to our stigman-orchestration repo that usess our demo keycloak image (not the CAC one) and removes the mtls requirement from nginx:
https://github.com/NUWCDIVNPT/stigman-orchestration/tree/demo-auth-no-CAC
It makes changes to the docker-compose.yml and nginx.conf files.

This orchestration uses our demo auth container, which has pre-canned users and an admin, and does not require CAC. The passwords are public, here:
https://hub.docker.com/r/nuwcdivnpt/stig-manager-auth
You will want to change all these, and create your own users.
You'll also need to provide your own certs to nginx in order to offer https outside of localhost.
You'll probably need to configure backups of the MySQL database as well as keycloak's own db, log aggregation, etc. to make the system ready for a production environment.

It should be possible to offer CAC or username/password auth, but would require changing the browser authentication flow in Keycloak. Their docs may be able to help you get there, but we do not have experience there.
If your org is already supporting a keycloak that offers auth the way you want it for other systems, perhaps the admin of that keycloak could configure it to provide OIDC for STIGMan?

[hearts1137]

@cd-rite thanks for creating that repo for us. It is appreciated. Having a bit of trouble accessing the site remotely though. I keep getting an error "failed to get: https://keycloak/kc/realms/stigman/.well-known/openid-configuration" when accessing the site by IP or DNS name. Localhost works just fine on my Windows box and using your repo files without any modifications.

https://github.com/NUWCDIVNPT/stigman-orchestration/blob/1edfe662edd301b5d50b2fa2ec24ba4022946f3b/docker-compose.yml#L12
Line 12 & 13 are where I put my DISA NPE .cer file and the .key from the CSR I created. That's the only modification I have made.

I get the feeling I am not presenting the cert from DISA to nginx properly. I have noticed the provided localhost.key is different that my private key I used for the NPE cert. The localhost.key starts with
-----BEGIN RSA PRIVATE KEY-----
and mine starts with
-----BEGIN PRIVATE KEY-----
Would that be enough to make remote connections fail?

date=2024-05-19T15:26:28.360Z component=oidc type=discovery data={"success":false,"metadataUri":"http://keycloak:8080/realms/stigman/.well-known/openid-configuration","message":"connect ECONNREFUSED 172.22.0.4:8080"} 1 date=2024-05-19T15:26:33.364Z component=oidc type=discovery data={"success":false,"metadataUri":"http://keycloak:8080/realms/stigman/.well-known/openid-configuration","message":"connect ECONNREFUSED 172.22.0.4:8080"} 3 date=2024-05-19T15:26:39.048Z component=oidc type=discovery data={"success":true,"metadataUri":"http://keycloak:8080/realms/stigman/.well-known/openid-configuration","jwksUri":"http://keycloak:8080/realms/stigman/protocol/openid-connect/certs"}

edit: forgot to mention, the keycloak screenshots I provided are from a managed platform service we use. No way they would assist me with this effort.

[cd-rite]

@hearts1137 It sounds like you are getting close....
I don't think the private key headers would make a difference.

From your error, it looks like your STIGMAN_CLIENT_OIDC_PROVIDER value is wrong. This URL needs to be from the perspective of the client. So it would be something like https://YOUR-SITE-URL/kc/realms/stigman
You can test this by going to https://YOUR-SITE-URL/kc/realms/stigman/.well-known/openid-configuration from your browser and getting a response.

Your STIGMAN_OIDC_PROVIDER (the internal url the API uses) seems right, since the last log entry for oidc says "success": true.

[hearts1137]

@cd-rite I got it working, thanks to you!

I added my cert info to lines 12 & 13. I did change the .key file to match the type provided by the repo with the command
openssl rsa -in cd-rite.fanclub.mil.key -out private.key
Then I changed lines 27 & 28 to match my certificate SAN (it's a wildcard cert) ex: https://stigman.cd-rite.fanclub.mil/kc
Line 45 I left alone but changed 46 to my domain; ex. https://stigman.cd-rite.fanclub.mil/kc/realms/stigman

I had to download the containers from my windows laptop using Docker desktop and export as .tar files to put in my air-gapped cloud environment. I used this site as a guide: https://medium.com/@nergaard/pull-docker-container-image-offline-bd25c5027cd9

I then had to get all the docker software on RHEL 8 which does not come in the default repositories (heckin EPEL). I used this as a guide and with my personal developers account, downloaded the rpm files and uploaded to my cloud; https://help.hcltechsw.com/bigfix/10.0/mcm/MCM/Install/install_docker_ce_docker_compose_on_rhel_8.html with the command dnf install docker-ce docker-ce-cli --downloadonly --downloaddir /root/rpms. On my cloud system we have an offline RHEL 8 repo and I had to install some apps to satisfy dependencies; yum -y install libcgroup fuse-overlayfs

I used portainer to export images but you can also use the CLI as the guide shows. Portainer let's you export all the images in a single file. I also wanted portainer because my RHEL 8 system is just CLI and portainer gives me easy access to the logs and settings of docker.
docker load -i docker_portainer.tar && docker volume create portainer_data && docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

In the end, I uploaded the following files to my cloud for use;
containerd.io-1.6.31-3.1.el8.x86_64.rpm
container-selinux-2.229.0-1.module+el8.9.0+21697+6a5e98e7.noarch.rpm
docker-buildx-plugin-0.14.0-1.el8.x86_64.rpm
docker-ce-26.1.3-1.el8.x86_64.rpm
docker-ce-cli-26.1.3-1.el8.x86_64.rpm
https://github.com/docker/compose/releases/download/v2.27.0/docker-compose-linux-x86_64 (renamed to docker-compose like the guide says to, copied to /usr/loca/bin, made executable and linked)
docker-compose-plugin-2.27.0-1.el8.x86_64.rpm
docker_portainer.tar
images.tar
stigman-orchestration-demo-auth-no-CAC.zip

Thank you for your help @cd-rite could not have gotten this far without it.

[danielcornwell615]

@hearts1137 Really glad to hear you got this working in your environment, gives me hope! I'm trying to use the new branch that the NAVSEA team provided in this post but with TLS across the network (I'm using self-signed certs) and I feel like I'm close to getting it working... but I get a splash page (see attached) when I bring the stack up that says "It worked! You did it! ... something was wrong reading the CAC certificate" I can get to Keycloak no issue but the stigman front-end isn't presenting the application, just a splash page. Maybe my yaml is missing an envvar? Issue with the cert? Maybe I'm going to the wrong URL? https://hostname:443 is what I'm using. https://hostname:443/kc/ will get me to KC. SSL handshake is failing accordin to nginx logs. I've also attached my yaml, nginx conf and nginx logs; any input or suggestions would be greatly appreciated!

[cd-rite]

Hi @danielcornwell615 Not sure if this is the issue, but it looks like in your "bad gateway" screenshot, you are trying to get to dj-stigman-1v but all your config points to dj-stigman-2v. That "you did it!" message is from nginx at the root, and the CAC warning should be able to be ignored since you aren't using CAC. For STIGMan, you should be hitting the addresshttps://hostname:443/stigman/

If you double check the above and still have issues, your STIGMAN_OIDC_PROVIDER value might be wrong. This sets the provider for the API (as opposed to the client) which should be able to use the "keycloak" alias, and so you should be able to keep:
- STIGMAN_OIDC_PROVIDER=http://keycloak:8080/realms/stigman
(It should also be possible to use the external hostname as you have it now, but that would need httpS and the /kc/ to be part of the url since it would be traversing the network)

Your last screenshot hitting keycloak shows some other addresses in the response that I would not expect ("wpc-stigman-1v...."). So maybe you aren't hitting the keycloak you think you are? I don't see anything that would make it think those are it's URLs in your config....

Your API logs (which get output to STDOUT) should indicate whether it is having success getting to Keycloak. You might have to be a little patient, since Keycloak starts up slower than the API. You'll get some success = false messages but then eventually something like date=2024-05-19T15:26:39.048Z component=oidc type=discovery data={"success":true,"metadataUri":"http://keycloak:8080/realms/stigman/.well-known/openid-configuration","jwksUri":"http://keycloak:8080/realms/stigman/protocol/openid-connect/certs"}

[danielcornwell615]

@cd-rite. Your attention to detail is second to none lol... the host names are fictitious as to not post my orgs info online. I must have fat fingered the 1v instead of 2v... but on my production config files all the FQDNs are matching. Regarding the NGINX config... can I leave those proxy_pass values as they are (stigman 54000 and keycloak 8080)?

I'll go ahead and change the OIDC_PROVIDER value back to the keycloak 8080 one that is standard and hopefully that does the trick. I'll update the post if/when i get it working with additional details, thanks!

Really appreciate the reply, take care.

-DJ

[cd-rite]

Hi @danielcornwell615 Ahhhh, ok. I wondered if that was it but figured I'd mention it anyway!
Yep, those proxy pass values should stay the same... That's how those components are known to nginx, since it's in the same orchestration. That's why you need the /stigman/ in the URL... it's proxying external https://hostname/stigman/ requests and passing them on to the API at http://stigman:54000 in its orchestration.

[danielcornwell615]

@cd-rite

Getting closer... I now get served the web-app via https://hostname:443/stigman

… but when I input my credentials I receive a "failed to register" error message, which also references an SSL certificate error.

Funny thing is it shows up as an active session within KC, but I am unable to get into the STIG Manager application.

I'm hoping this is just an issue with the self signed certs I'm using or something related to that, but I figured I'd post it in case it's a glaringly obvious issue to someone more seasoned than me.

Looking at the NGINX logs, I see a lot of failed SSL handshakes...

[csmig]

Maybe one of these links will advance the troubleshooting. Your browser does not trust your self-signed certificate enough to accept it in a non-interactive context like fetching and registering a service worker.

https://stackoverflow.com/questions/38728176/can-you-use-a-service-worker-with-a-self-signed-certificate

https://mswjs.io/docs/recipes/using-local-https/#:~:text=SecurityError%3A%20Failed%20to%20register%20a,and%20MSW%20will%20not%20work.

[danielcornwell615]

@csmig @cd-rite
So after doing some digging around I found a solution. Downloaded Firefox and the web-app works perfectly fine using the self-signed certs in that browser ... still cannot get it to work in Chrome or Edge. Going to continue messing with those settings/flags but at least I was able to isolate the problem to a browser issue. Thank you guys for all the feedback/support!

[cd-rite]

@danielcornwell615 Excellent! Perhaps it's because Edge and Chrome use the same Chromium engine under the hood. You could try clearing site data/certs in Chrome, to see if that helps: https://github.com/NUWCDIVNPT/stigman-orchestration?tab=readme-ov-file#notes

[danielcornwell615]

@cd-rite @csmig
Still working out a couple bugs with our STIGman instance (nginx container needs to be manually started, but after that it works) but one thing caught my eye specifically... I received an error when importing a CKL stating max character limit 255 (see error below) and did some digging on your GitHub. Seems like this might be related to an issue that was previously addressed already #1250 , but I'm curious if the branch that you guys pushed in this thread
https://github.com/NUWCDIVNPT/stigman-orchestration/tree/demo-auth-no-CAC incorporates that change. If not, how can I go about verifying/fixing it on my own?

Also, when importing CKLs I noticed there is a column for "rejected" relating to the checks (I assume). Upon import, I am receiving several rejected checks but the rest of the CKL imports fine. Could this be due to the fact that my organization is way behind on their STIGs and the CKLs I'm importing are from like 3-4 revisions ago (2021, 2022)? I am using the latest Benchmark Compilation from DISA.

As always, thank you for your time.

-DJ

[cd-rite]

Hi @danielcornwell615 That 255-character error is referring to the ip address field in the .ckl you are trying to import. If you shorten the value in that field in your .ckl to under 255 characters, it should resolve that error.

And yes, those "rejected" reviews are almost certainly because STIGMan does not know the Rule you are importing for. If you dig up the old version of those Reference STIGs, and import them, then try again, it should work, but they would be quite out of date by now!
Also, note the Reviews for old Rules will only show up in your checklist if you have selected that old Revision of the STIG (Or if the rule check content and "STIG Id" are an exact match in the new Rule.)

[danielcornwell615]

@cd-rite I was able to fix the 255-character error by manually changing the IP field in the CKL as you suggested, thanks!

The Rule Rejection error is still an issue and is apparently not being caused by out-dated CKLs.

I went ahead and ran all new/fresh STIGs with the latest benchmarks and still getting the same behavior from the app when I go to import.

It states the reason for the rule rejection is "no grant for this asset/rule ID". I'm receiving no errors in my container logs.

I verified that I am the owner of the collection and I have all the roles assigned to the user account in Keycloak.

At this point, I'm stumped.

[cd-rite]

Hi @danielcornwell615 It looks like your checklist is not based on the latest RHEL STIG Benchmark, which does not have those RuleIds. If you import the V1R13 version of the RHEL Reference STIG then your checklist should import. From our STIG compare tool, comparing R13 to R14, you can see that that first STIG rule ID you had an issue with has changed:

[danielcornwell615]

@cd-rite That worked... my bad, I used last month's e-stig by mistake. So, moving forward from this latest DISA STIG release it shouldn't be an issue, it's just moving backwards that will take a bit more effort... but who wants to move backwards lol? This is a GREAT excuse to ensure all the system owners are using the very latest STIG releases. Thanks!

[13sward]

I made a docker orchestration around 8 months ago that used nginx proxy manger (GUI) and duckdns pointed to a local IP to get a fully valid SSL cert for stigman to deploy over a local network with UN/PW auth. Requires minimal effort to get the cert setup in nginx proxy manager and it's really user friendly. I can't remember everything that I changed in the orchestration but I messed with keycloaks auth flow and disabled strict hostname checking. Let me know if yall want me to send it id be happy to. DISCLAIMER (NOT FOR PROD USE).