Shibboleth without SSL - docker

Q: Is it possible to deploy Shibboleth without SSL?
Intro: We need to deploy Shibboleth in our testing environment. This environment is not visible from the Internet, so we are not able to add some valid certificate -- so it warns us that we are using a self-signed certificate. Our app can't go through this warning, and we are not able to automatically test if login via SAML works properly.
We use a docker image shibboleth-idp with our setup.
I think that we can change settings of Jetty and turn off SSL, but I am not sure how and if Shibboleth will be OK with that.

Question: "we can change settings of Jetty and turn off SSL, but I am not sure how and if Shibboleth will be OK with that."
Answer:
(1) Yes. Shibboleth is OK without SSL for demo purpose only. In other words, on the testing environment, you can change settings of Jetty and turn off SSL, and then run Shibboleth IdP with Jetty on the HTTP port of 8080 instead of the HTTPS port of 8443.
I have validated SAML authentication/federation provided by Shibboleth IdP/Jetty/HTTP port:8080 without SSL for Shibboleth SP. In other words, Shibboleth IdP runs on the Jettp HTTP port 8080 (instead of HTTPS port 8443) provides SAML authentication/federation for Shibboleth SP successfully.
Remarks:
(I) Usually the deployment of Shibboleth IdP on the production environment leverages proxy to redirect external HTTPS port 443 to internal HTTPS port 8443 of Jetty.
Correspondingly the deployment of Shibboleth IdP on the testing environment leverages proxy to redirect external HTTPS port 80 to internal HTTPS port 8080 of Jetty.
(II) Shibboleth IdP should run on Jetty with HTTPS port when deployed on the production environment.
(2) Security And Networking of Shibboleth IdP demonstrates that Jetty HTTPS key and certificate are NOT the keys and certificates used by Shibboleth IdP, which indicates that Shibboleth is OK without SSL for demo purpose only.
Use of browser-facing TLS key and certificate
This key and certificate is not used by Shibboleth directly, and you SHOULD NOT use this key (or certificate) in any of the other capacities described below.
(3) How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository provides the instruction on building a SAML-based Authentication/Authorization Provider using Shibboleth SAML IdP and OpenLDAP.
Shibboleth SAML IdP is responsible for identity federation.
OpenLDAP is responsible for identity authentication.
(I) To run Shibboleth IdP with Jetty on the HTTP port of 8080, you only need to execute the commands below to modify the configuration before building both IdP and SP Docker images. For your convenience, the Shibboleth IdP without SSL provided by this GitHub repository has been validated.
cd shibboleth-idp-dockerized/ext-conf/conf/
cp idp.properties idp.properties.backup
cp idp.properties.without.ssl idp.properties
cd -
cd shibboleth-idp-dockerized/ext-conf/metadata/
cp idp-metadata.xml idp-metadata.xml.backup
cp idp-metadata-without-ssl.xml idp-metadata.xml
cd -
cd shibboleth-sp-testapp/shibboleth-sp/
# Edit shibboleth2.xml to update IdP entityID and metadata without SSL.
vi shibboleth2.xml
<SSO entityID="https://idp.example.com/idp/shibboleth">
-->
<SSO entityID="http://idp.example.com/idp/shibboleth">
<MetadataProvider type="XML" file="idp-metadata.xml"/>
-->
<MetadataProvider type="XML" file="idp-metadata-without-ssl.xml"/>
(II) I have validated SAML Single Sign-On (SSO) provided by Docker-running Shibboleth SAML IdP (Identity Provider) and OpenLDAP for the following enterprise applications. In other words, I leveraged Docker-running Shibboleth SAML IdP and OpenLDAP to log in to the following enterprise applications successfully.
Microsoft Office 365
Google G Suite
Salesforce
Dropbox
Box
Amazon AWS
OpenStack
Citrix NetScaler
VMware vCloud Director
Oracle NetSuite
(III) Another StackOverflow question Setting up a new Shibboleth IdP to work with an existing SAML SP discusses the SAML configuration between IdP and SP.

Related

Jhipster registry "Status: (Unauthorized)" page after keycloak login

Jhipster registry:v3.3.0
Keycloak: 4.5.0.Final (https enabled)
There is a jhipster registry setup using docker-compose as shown in picture. Registry talks to Keycloak for authentication.
We have two keycloak instances.
When configured with one keycloak instance it successfully logins and opens the registry page.
When configured with other keycloak instance it show the following page:
After entering keycloak credentials, the url in the browser is http://localhost:8761/login?state=Swy20H&session_state=c6853b18-42f3-4ad9-9ad0-14615aa576bd&code=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..xtptsARyYJPbqrhZD4ZF7A.yKur_w3c5H-ybHcpXeBSca1W7N3XxRzQXaUs383Kqh57wzaWt3FhBglGf-w154GRTM93F5oa2grE8HzVyrRpDadQs5FCjpNDZuD86KZy5JVI4RnlYOFvsTMcO-fFi_bWl2ByvNy7QARglrwGQOTeYndvrYluuC57OJGKm8819gIb9a5wvZ9oeiJLuDPwkcefs2J-xnUvEde3yAyVKGxe_oGdA8jJbbwRDQQvCI2e3FLyiKJ1F2P2iHFT5g_QaQxv.7k__JisYiWQrQpjgxJ8m5Q
Same keycloak client was imported in Keycloak realm for instances. Any idea what could be the reason?
I had faced similar issue.
In my case I was getting it because of two reasons.
The keycloak was SSL enabled and the keystore file used in this
process did not include Root certificate. Refer this SOS.
Our network firewall was blocking the requests to Auth Server. In your case it could be Jhipster registry's backend
you must change configuration in docker file inside your server if you use docker and when enable SSL you must mapping new URI in each docker file
i have the same problem and this is solution for that
- SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OIDC_ISSUER_URI=http://127.0.0.1/auth/realms/jhipster
but after enable ssl your service cannot show above url you must be change it to
- SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OIDC_ISSUER_URI=https://your-domain.eg/auth/realms/jhipster
after that you can authentication without any problem

AzureAD authentication to Icingaweb2

Is it possible to authenticate to Icingaweb2 through AzureAD (SAML/oauth2/openID) ?
This thing is actually possible to achieve with usage of
https://github.com/bitly/oauth2_proxy
After this proxy is installed and configured, run it with -set-xauthrequest info is in github repo wiki/readme
Set up icingaweb2 for external authentication by adding:
[autologin]
backend = external
into authentication.ini file
In icingaweb2 you need to add:
fastcgi_param REMOTE_USER $http_X_User;
into nginx/apache configuration.
If you will use same cookie name and secret pair in oauth2 proxy configuration, you will be authenticated to all your systems (Graylog SSO plugin, Icinga2, any your site) with pure SSO experience.
Depending on how much information is available, you can add a custom application to Azure AD.
This way only allows the connection to be SAML.

Https Security Integration with Camunda BPM

I have used ldap based camunda-auth to login to the application using HttpBasicAuthenticationProvider provided by camunda, where how can I implement https login and is it supported by camunda (or) we need to use spring security?
Please send any link related or config to camunda - https implementation.
I am not sure I understood you correctly- you want to set up camunda to have TLS and additionally you want LDAP authorization?
To set up TLS, you need to configure it directly on Tomcat server.
First you need to obtain/generate certificates.
Then you need to point to those certificates in server.xml configuration file.
Just google "TLS on Tomcat". I'm sure there are hundreds of tutorials how to do this step by step.
When it comes to LDAP integration - follow documentation:
https://docs.camunda.org/manual/7.8/installation/full/tomcat/configuration/#ldap

Should we require to install sitemind web agent to both system in java

I have one application says "app1"(main application support login) which is deploy some different machine tomcat server and another application says "app2" which also deployed in another machine tomcat server. So, should i need to install siteminder web agent to both the machine or it is on only in "appl2"?
Depends on what kind of agent you are using- if you're using a web agent for a web server (IIS, Apache), you could just install it on that box assuming it handles requests to both app servers. If you are installing the agent for the app server, Siteminder could log the user into the app on the "app1" server, and then the app/app server token could be passed to "app2"
You can use a traditional reverse proxy (apache with mod_proxy) or SiteMinder Secure Proxy Server to handle the Web Agent work and forward traffic to the destination web/app servers.
Secure Proxy Server enables your Single Sign-On environment to have "agentless" capabilities. You will still have 1 or more SiteMinder Web Agents (depending on the number of proxies that are deployed), but the web and application servers will not need to have any agents installed. The web/app servers only need to be able to consume the HTTP Headers provided by SiteMinder.

Spring Security, OpenID, and mod_proxy

I have an application using spring-security's OpenID implementation. The app server sits behind a proxy. The proxy is apache httpd with mod_proxy. If the proxy connects to the app server via HTTP, the application will tell the OpenID authenticator to redirect back via HTTP rather than HTTPS like I would prefer. It seems to pull the protocol dynamically and only sees HTTP. If I configure the proxy to use HTTPS, I run into this problem. So is there a way to operate spring security behind a proxy which uses HTTP?
A little extra mod_proxy and Glassfish configuration solved this problem for me:
https://serverfault.com/questions/496888/ssl-issue-with-mod-proxy

Resources