Support for safe control of uploadable contents from console

In couple of cases configuration of authenticators and endpoints rely on configurable files from local FS, or URIs which can also resolve the file: scheme. We need to support them securely in console, providing option to upload a desired value, but not allowing to select a file from the installation site.

FS path use cases

• unity.saml.requester.metadataSource - authenticator

• unity.saml.metadataSource - endpoint

• web contents directory of endpoint

unity.saml.requester.metadataSource and unity.saml.metadataSource configuration options type changed to URI. Will require note about this change in upgrade docs, though no reconfiguration should be necessary in most cases as path should be a valid URI without the scheme. Some problems may be with paths with spaces. Respective *Properties classes should check the syntax . Note: schema-less URI should be treated as URI with ‘file:’ scheme.

The last one stays as-is but is not exposed on console in any way.

URI in config/console handling

URI/URL allowed to be configured:

Authenticators:

• retrieval.sms.logoURL

• retrieval.tls.logoURL

• unity.oauth2.client.CLIENT_ID .iconUrl[.*]

• unity.saml.requester.metadataSource .*.url

• unity.saml.requester.remoteIdp.* .logoURI[.*]

Endpoints:

• unity.endpoint.web.authnScreenLogo

• unity.saml.acceptedSPMetadataSource .*.url

• unity.saml.acceptedSP.* .logoURI[.*]

Other in existing code:

• Logo path in registration/enquiry form Visual settings

URI handling

Introduce a new boolean, global option (unityServer.conf) restrictFileSystemAccess, by default false.

Introduce a new service: FileStorageService with more or less the following API:

Introduce a new service URIAccessService:

Make sure FSS and URIAS are used for all file related IOs in the cases enumerated in the leading section. Also scan the code for other cases where file IO is done or URL or URI based operations and check if this service shouldn’t be used. Basically only very internal, low level operations may be done without it (like loading unityServer.conf etc). THAT IS VERY IMPORTANT.

FSS implementation should recognize URI schemes as follows when file is read:

• no scheme or file:

• restrictFileSystemAccess=true - file is served from disk, relative paths resolved against $ROOT

• restrictFileSystemAccess=false - file is served from disk only if it is physically located in webContents. Relative paths resolved against $ROOT

• unity.internal: file is served from DB.

$ROOT value depends whether we have readFile or readImageFile: either Unity installation root (should be the same as current relative path for unity.saml.requester.metadataSource) or current theme root.

storeFile should always return unity.internal: URI after placing the file in DB. the path of URI should include UUID of the file. The UUID should be stored in table in DB. The table should be separate, with columns: ID, UUID, OWNER_TYPE, OWNER_KEY, DATA (BLOB) . Owner should mark whose file it is, e.g. oauthAuthenticator authenticatorKey.optionId.logo

For UI part in console:

• whenever we allow to enter an URI it must pass the test isWebReady

• whenever file is uploaded, it is stored with FSS and obtained URI is placed in stored config.

• whenever we have a URI in configuration that is not isWebReady, then we don’t show it as URI, only show the contents as obtained from FSS.