Have you looked into Sling Commons Crypto? https://sling.apache.org/documentation/bundles/commons-crypto.html
It would not be complete prevention, but at least that way the secrets aren't stored plain-text. Of course even with that a malicious bundle could retrieve the private configuration from the OSGi Config Manager, retrieve the correct Crypto instance and decrypt the messages, but it would require access to a properly configured instance. This would prevent someone from reading the values directly from the console or exporting the app, starting it somewhere else and reading the values from the config. On Mon, Feb 8, 2021 at 12:53 PM Cris Rockwell (Jira) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/SLING-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281261#comment-17281261 > ] > > Cris Rockwell commented on SLING-9397: > -------------------------------------- > > {quote}Who are you trying to protect the sensitive data from? As far as I > can > tell Sling is mostly being run in a single-tenant manner and there is > no effort to make it multi-tenant.{quote} > {quote}If you're trying to make it safe from malicious code deployed in the > same JVM, I'd say that all bets are off already.{quote} > Yes. My concern is making it harder in case of RCE or malicious Java > bundles. I get the idea that ‘all bets are off’ in those scenarios. > Security training instructs us to think in terms of layers. In keeping with > the principle of least privilege; if these data aren't needed by other > services and those services aren't fully trusted, then I should consider > access control more carefully. That's why I'm considering simplifying the > project structure to eliminate the config service and placing all the > component and services within the same package, and using package private > scope. > > > > > SAML2 Authentication Handler [initial submission] > > ------------------------------------------------- > > > > Key: SLING-9397 > > URL: https://issues.apache.org/jira/browse/SLING-9397 > > Project: Sling > > Issue Type: New Feature > > Components: Authentication > > Environment: localhost > > Reporter: Cris Rockwell > > Assignee: Cris Rockwell > > Priority: Major > > Labels: SAML, authentification, security, user_management > > Original Estimate: 168h > > Time Spent: 1h 20m > > Remaining Estimate: 166h 40m > > > > Here is a pull request which adds an authentication handler for a SAML2 > Service Provider via the embedded OpenSAML V3 dependencies > > [https://github.com/apache/sling-whiteboard/pull/51] > > > > *TODO Before Initial* > > [X] Sync attributes released by the IDP > > [X] Confirm license and attribution > > "As the code is ASL2 and does not require a notice or anything else, we > don't need to mention in. But I think its usually good style to do so and > have a single sentence in our NOTICE that we include (modified) code from > ... which has ASL2 as the license" > > > > *TODO After Initial* > > [X] Get confirmation the project builds and operates as expected > > [X] Ensure that the NOTICE file is the correct one > > [X] Testing setup ( documentation, local SAML provider, etc ) > > [X] Clarify whether we can depend on artifacts not deployed on Maven > Central > > [X] Review Web Browser SSO Profile Specification 4.1 and confirm all > aspects > > * [ > https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf] > > [X] Decide whether to make signing and encryption optional. Currently it > is required > > [X] Get feedback whether README instructions are too much, too little, > unclear, etc > > [ ] Consider whether use > of {{SAML2ConfigService}} and {{SAML2ConfigServiceImpl}} is a good design > or not. > > [ ] Find and fix any bugs. > > > > > > -- > This message was sent by Atlassian Jira > (v8.3.4#803005) >
