Migrate
Panopticon started to use Spring Security in 2024.1, and with this came changes to the security-related configuration. One major difference is that we decided to move the security settings to the new <appdata>/security.yml file.
This was done for two reasons. First, the Panopticon.properties file cannot have comments, and explicitly lists every available property, even the ones with default values and the ones that are not used. Second, many Spring properties have very long and repeated prefixes, and the YAML format makes this much easier to read.
The properties that have moved all start with authentication. or access. and your original ones in Panopticon.properties will be left there after upgrading, but you will get a warning message in the server log each time it starts until you have moved them out of there. Also note that authentication method-related properties have changed radically.
You now select authentication method by configuring it. For example, if you previously had OLAP and SAML properties set up, and switched between them with authentication.type, you can now have both configured in security.yml and switch by commenting one of them out.
Spring Security now provides web application protection, so it takes over some aspects that were previously handled by Tomcat. For example, some security headers and the CORS filter are now configured in security.yml too.
Miscellaneous
The authentication.token.secret value has moved out into the <appdata>/token_secret file. It should get migrated automatically, but you may want to double-check that the file contents are the same as the old value. This makes sure that JWT token cookies issued by the old server are still valid but is also important if you manually configured this value (e.g., to run servers in a cluster).
The authentication.logout.redirect.url property is now named authentication.logout.success-url and is set in security.yml.
Username and Password
If you used <tomcat-home>/conf/tomcat-users.xml to list your users, you need to move them from there into <appdata>/users.xml. Note that the syntax is different, and because the Spring Security format expects hashed passwords by default, you need to prefix them with {noop} if you want to store them in clear text.
NOTE: authentication.type=BASIC is no longer needed. Username and password are the default method.
LDAP
Previously, you would configure LDAP through a JNDI realm in the Panopticon web application’s context file, e.g., <tomcat-home>/conf/Catalina/localhost/panopticon.xml, or possibly globally in web.xml. You now do it in security.yml instead, and the property names are different from the XML attributes you used:
| Realm Attribute Name | Property Name |
|
connectionURL |
spring.ldap.urls |
|
connectionName |
spring.ldap.username |
|
connectionPassword |
spring.ldap.password |
|
userPattern |
authentication.ldap.user-dn-patterns |
|
userBase |
authentication.ldap.user-search.base |
|
userSearch |
authentication.ldap.user-search.filter |
|
roleBase |
authentication.ldap.group-search.base |
|
roleSearch |
authentication.ldap.group-search.filter |
|
roleName |
authentication.ldap.group-role-attribute |
NOTE: You no longer need authentication.type=BASIC. This meant username and password authentication (of which LDAP is a special case) and this is now the default.
OAuth 2.0
If you had OAuth configured in Panopticon.properties, you would only need a few values from there. Move them into security.yml as follows:
- authentication.oauth2.client.id goes to client-id in the registration.
- authentication.oauth2.client.secret becomes client-secret.
- authentication.oauth2.login.scope becomes scope but comma-separated.
- authentication.oauth2.login.url becomes issuer-uri but remove the endpoint path.
- authentication.oauth2.identity.attribute.username becomes authentication.oauth2.username-claim but only if it’s not preferred_username.
- authentication.oauth2.identity.attribute.roles becomes authentication.oauth2.groups-claim but only if it’s not groups.
IMPORTANT: The endpoint in Panopticon that the OAuth server should redirect to after authentication has changed in, what you used to have in login.callback.url, from /server/rest/auth/login, to the Spring Security standard path /login/oauth2/code/<reg-name>. You need to update the sign-in redirect URI or similar on the OAuth server side to reflect this.
Also note that Panopticon now has support for OpenID Connect (OIDC), which it previously didn’t, so if you had to tweak the configuration before to avoid OIDC, you no longer must do that.
For example, if your Panopticon.properties had this:
authentication.oauth2.client.id=0odfhiuhvb5d7
authentication.oauth2.client.secret=r7rFsdgkjsdgpUXB
authentication.oauth2.identity.attribute.roles.pattern=
authentication.oauth2.identity.attribute.roles=pano-groups
authentication.oauth2.identity.attribute.username=preferred_username
authentication.oauth2.identity.method=HEADER
authentication.oauth2.identity.url=https\://dev-8052349.okta.com/oauth2/v1/userinfo
authentication.oauth2.login.callback.url=http\://company.org/panopticon/server/rest/auth/login
authentication.oauth2.login.redirect.url=
authentication.oauth2.login.response.type=code
authentication.oauth2.login.scope=openid profile groups
authentication.oauth2.login.url=https\://dev-8052349.okta.com/oauth2/v1/authorize
authentication.oauth2.logout.redirect.url=
authentication.oauth2.logout.url=https\://dev-8052349.okta.com/oauth2/v1/logout
authentication.oauth2.token.method=BODY
authentication.oauth2.token.url=https\://dev-8052349.okta.com/oauth2/v1/token
authentication.type=OAUTH2
Then your security.yml should look like this:
spring.security.oauth2.client:
registration:
our-okta-app:
client-id: 0odfhiuhvb5d7
client-secret: r7rFsdgkjsdgpUXB
scope: openid, profile, groups
provider:
our-okta-app:
issuer-uri: https://dev-8052349.okta.com
authentication.oauth2.groups-claim: pano-groups
And you should change the sign-in redirect URI (or similar) on your OAuth server from http://company.org/panopticon/server/rest/auth/login to http://company.org/panopticon/login/oauth2/code/our-okta-app.
SAML 2.0
If you had SAML configured in Panopticon.properties, you would only need a few values from there. Move them into security.yml as follows.
- authentication.saml.identityprovider.url can be used to guess the metadata-uri (try appending /metadata to it), but it’s safer to look it up on the SAML server side.
- authentication.saml.assertion.username becomes authentication.saml2.username-attribute, but if the NameID in your SAML responses already has the username you can just leave it out.
- authentication.saml.assertion.roles becomes authentication.saml2.groups-attribute but only if it’s not groups.
IMPORTANT: The endpoint in Panopticon that the SAML server should redirect to after authentication has changed in what you used to have in assertionconsumerservice.url from /server/rest/auth/login () to the Spring Security standard path /login/saml2/sso/r<eg-name>. You need to update the single sign-on URL or similar on the SAML server side to reflect this.
For example, if your Panopticon.properties had this:
authentication.saml.assertion.roles=pano-groups
authentication.saml.assertion.username=uname
authentication.saml.assertionconsumerservice.url=http\://company.org/panopticon/server/rest/auth/login
authentication.saml.certificate.name=1
authentication.saml.certificate.password=wasspord
authentication.saml.challenge.required=true
authentication.saml.identityprovider.certificate.file=/pano-creds/okta.cert
authentication.saml.identityprovider.logout.url=
authentication.saml.identityprovider.signature.validation.required=true
authentication.saml.identityprovider.url=https\://dev-8052349.okta.com/app/panosaml/exki7b0XIFO5d7/sso/saml
authentication.saml.keystore.file=/pano-creds/key.p12
authentication.saml.keystore.password=wassport
authentication.saml.keystore.type=PKCS12
authentication.saml.login.redirect.url=
authentication.saml.logout.redirect.url=
authentication.saml.openam.meta.alias=
authentication.saml.protocolbinding=
authentication.saml.provider=OPENSAML
authentication.saml.serviceprovider.id=http\://www.okta.com/exki7b0XIFO5d7
authentication.type=SAML
Assuming NameID already had the same value as the uname attribute, then your security.yml should look like this:
spring.security:
saml2.relyingparty.registration:
our-okta-app:
assertingparty:
metadata-uri: https://dev-8052349.okta.com/app/panosaml/exki7b0XIFO5d7/sso/saml/metadata
signing.credentials:
- private-key-location: file:/pano-creds/key.pem
certificate-location: file:/pano-creds/cert.pem
authentication.saml2.groups-attribute: pano-groups
And you should change the single sign-on URL (or similar) on your SAML server from http://company.org/panopticon/server/rest/auth/login to http://company.org/panopticon/login/saml2/sso/our-okta-app.
NOTE: Spring Security wants the signing credentials as two separate files: the private key and the public certificate. You may need to export them from your keystore.
(c) 2013-2024 Altair Engineering Inc. All Rights Reserved.