[
https://issues.apache.org/jira/browse/BROOKLYN-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16365356#comment-16365356
]
Richard Downer commented on BROOKLYN-577:
-----------------------------------------
Information on the Brooklyn mailing lists can be found at
https://brooklyn.apache.org/community/mailing-lists.html.
I note that your comment was marked as "Restricted to jira-users" which meant
it cannot be seen by anyone not logged into Jira. Please avoid restricting Jira
content, we prefer to keep all but the most sensitive material open to all.
> GSoC: Modernise Brooklyn's authentication system
> ------------------------------------------------
>
> Key: BROOKLYN-577
> URL: https://issues.apache.org/jira/browse/BROOKLYN-577
> Project: Brooklyn
> Issue Type: Improvement
> Affects Versions: 1.0.0
> Reporter: Richard Downer
> Priority: Major
> Labels: cloud, gsoc2018, java, javascript, rest
>
> This is an idea for [Google Summer of
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon
> EC2. In more detail, it's a tool for describing applications and their
> components, deploying these applications to the cloud, and managing the
> ongoing health and responsiveness. Brooklyn does this using blueprints -
> human readable documents which describe in detail an application component,
> or a whole application. Blueprints are stored in a catalog, essentially a
> built-in database of components and applications. An application blueprint
> can call on component blueprints from the catalog, therefore allowing complex
> applications to be built from simple pieces.
> Apache Brooklyn currently uses a simple authentication/authorisation system.
> Runtime authentication relies on HTTP Basic Authentication. While this has
> been satisfactory for some time, it has many shortcomings. HTTP Basic
> Authentication caches credentials on the client side, which is a weakness.
> It's not possible for a server policy to enforce session expiry timeouts.
> Even trivial things such as providing a "logout" button are difficult to
> reliably implement. This makes enterprise adoption of Brooklyn problematic as
> it cannot comply with the security policy requirements that enterprises
> typically have.
> Apache Brooklyn's authorisation systems on the server side are basic.
> Usernames and passwords can be put into the server configuration by an
> administrator. This means that users do not have the ability to change their
> own password, and enterprise security policies such as password rotation
> cannot be supported. (As an alternative, Brooklyn can integrate with external
> directory services, but it is often overkill to deploy a heavy directory
> server alongside a Brooklyn server.)
> This project would be to overhaul Apache Brooklyn's login system to a modern
> system. Considerations include:
> * A built-in user directory that is easy to get started with yet which
> guides the administrator towards a secure system
> * Credentials stored in a secure manner
> * A login screen in the UI, and the appropriate API methods to log in and
> issue tokens
> * Revise the server side API code to validate tokens
> * UI and API support for logging out, changing password, other appropriate
> operations
> * UI and API support for an administrator to manage users
> * Security policy features such as:
> ** Logged in sessions expire after a fixed time
> ** User must change their password on first login
> ** User passwords expire after a fixed time and must be changed
> ** Lock out accounts after a number of failed logins
> ** Audit log
> * Retain ability to integrate with an external directory service
> This project will involve the use of Java for the server-side development
> (this is where most of the work will take place), and HTML+CSS+Javascript for
> the client-side development (this is less important as we expect others will
> be on-hand to help with the visual development). It will require study and
> implementation of "best practices" for security.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
