authelia/SECURITY.md

48 lines
2.4 KiB
Markdown
Raw Normal View History

# Security Policy
## Prologue
Authelia takes security very seriously. We follow the rule of
[responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure), and we urge our community to do so as
well instead of making the vulnerability public. This allows time for the security issue to be patched quickly.
If you discover a vulnerability in Authelia, please first contact one of the maintainers privately as described in the
[contact options](#contact-options) below.
We urge you not to disclose the bug publicly at least until we've had a
reasonable chance to fix it, and to clearly communicate any public disclosure timeline in your initial contact with us.
If you do not have a particular public disclosure timeline, we will clearly communicate ours as we publish security
advisories.
For more information about [security](https://www.authelia.com/information/security/) related matters, please read
[the documentation](https://www.authelia.com/information/security/).
[FEATURE] Automatic Profile Refresh - LDAP (#912) * [FIX] LDAP Not Checking for Updated Groups * refactor handlers verifyFromSessionCookie * refactor authorizer selectMatchingObjectRules * refactor authorizer isDomainMatching * add authorizer URLHasGroupSubjects method * add user provider ProviderType method * update tests * check for new LDAP groups and update session when: * user provider type is LDAP * authorization is forbidden * URL has rule with group subjects * Implement Refresh Interval * add default values for LDAP user provider * add default for refresh interval * add schema validator for refresh interval * add various tests * rename hasUserBeenInactiveLongEnough to hasUserBeenInactiveTooLong * use Authelia ctx clock * add check to determine if user is deleted, if so destroy the * make ldap user not found error a const * implement GetRefreshSettings in mock * Use user not found const with FileProvider * comment exports * use ctx.Clock instead of time pkg * add debug logging * use ptr to reference userSession so we don't have to retrieve it again * add documenation * add check for 0 refresh interval to reduce CPU cost * remove badly copied debug msg * add group change delta message * add SliceStringDelta * refactor ldap refresh to use the new func * improve delta add/remove log message * fix incorrect logic in SliceStringDelta * add tests to SliceStringDelta * add always config option * add tests for always config option * update docs * apply suggestions from code review Co-Authored-By: Amir Zarrinkafsh <nightah@me.com> * complete mocks and fix an old one * show warning when LDAP details failed to update for an unknown reason * golint fix * actually fix existing mocks * use mocks for LDAP refresh testing * use mocks for LDAP refresh testing for both added and removed groups * use test mock to verify disabled refresh behaviour * add information to threat model * add time const for default Unix() value * misc adjustments to mocks * Suggestions from code review * requested changes * update emails * docs updates * test updates * misc * golint fix * set debug for dev testing * misc docs and logging updates * misc grammar/spelling * use built function for VerifyGet * fix reviewdog suggestions * requested changes * Apply suggestions from code review Co-authored-by: Amir Zarrinkafsh <nightah@me.com> Co-authored-by: Clément Michaud <clement.michaud34@gmail.com>
2020-05-04 19:39:25 +00:00
## Contact Options
Several [contact options](./README.md#contact-options) exist, it's important to make sure you contact the maintainers
privately which is described in each available contact method. The methods include our [security email](./README.md#security),
[Matrix](./README.md#matrix), and [Discord](./README.md#discord).
## Credit
Users who report bugs will optionally be credited for the discovery. Both in the [security advisory] and in our
[all contributors](./README.md#contribute) configuration/documentation.
## Process
1. User privately reports a potential vulnerability.
2. The core team reviews the report and ascertain if additional information is required.
3. The core team reproduces the bug.
4. The bug is patched, and if possible the user reporting te bug is given access to a fixed version or git patch.
5. The fix is confirmed to resolve the vulnerability.
6. The fix is released.
7. The [security advisory] is published sometime after users have had a chance to update.
## Help Wanted
We are actively looking for sponsorship to obtain either a code security audit, penetration testing, or other audits
related to improving the security of Authelia. If your company or you personally are willing to offer discounts, pro
bono, or funding towards services like these please feel free to contact us on *any* of the methods above.
[security advisory]: https://github.com/authelia/authelia/security/advisories