Bug 2032411
| Summary: | [RFE] Add option to configure session timeout for Satellite server. | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Krutika Kinge <kkinge> |
| Component: | Settings | Assignee: | satellite6-bugs <satellite6-bugs> |
| Status: | CLOSED MIGRATED | QA Contact: | Satellite QE Team <sat-qe-bz-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.9.0 | CC: | apatel, lstejska, mhulan, oliver.langner, pjasbuti, sfroemer, ytale |
| Target Milestone: | Unspecified | Keywords: | FutureFeature, MigratedToJIRA, Reopened |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-06-06 02:17:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Krutika Kinge
2021-12-14 13:02:41 UTC
(In reply to Krutika Kinge from comment #0) > 3. Why does the customer need this? (List the business requirements here) > > - Due to internal security assessment cu need to force the session > termination after a particular time. > What value in terms of security does this feature provides? Terminate a idle-session is out of question and totally make sense, but terminate sessions after a specific point in time, will frustrate users and is completely against all common UX-patterns. I doubt such an implementation will increase the security and if combined with password-login, it will only make customers store passwords (and if password managers used, there is no problem) From a business value point of view, I expect a higher cost in management due to the fact the user in worst case will spend double time on activity, because the work is lost. Imagine following scenario: Reducing possibility of car theft To avoid the thief can drive the car far away, the default driving time is 30 minutes. After that, you will need to go out of the car, lock it, open it again, go into the car and start again. Now you can drive another 30 minutes. As you can see, there will be no increase in the security, as the car will still be stolen. But in most of the time, the owner of the car is unable to reach his workplace in a single ride, as the standard travel time is 45 minutes. Now I'm asking, how much benefit you expect to get from such a feature? I suppose nothing and I vote for decline of such a RFE. /Steffen CU referenced this requirement is based on NIST SP 800-53, control IA-11: --- Control name: Re-authentication Control text: Require users to re-authenticate when [Assignment: organization-defined circumstances or situations requiring re-authentication]. Discussion: In addition to the re-authentication requirements associated with device locks, organizations may require re-authentication of individuals in certain situations, including when roles, authenticators or credentials change, when security categories of systems change, when the execution of privileged functions occurs, after a fixed time period, or periodically. --- As a starting point, it would make sense to me to analyze if Satellite actually requires a user to re-authenticate for the described circumstances / situations from the control IA-11 or if this already applies when a logged-in user e.g. refreshes a page on the WebUI / commandline / API. In case Satellite does not require re-authentication, implementing the periodically fixed session logout does not add any value from a security perspective. In case any of the mentioned changes requires re-authentication, implementing the RFE to fulfill this control (IA-11) could add value on the costs of usability. Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team. Thank you. Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team. Thank you. Based upon feedback during auto-closure, leaving this bugzilla open a while longer for additional investigation; however, it may be closed in a future iteration. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |