[
https://issues.apache.org/jira/browse/BROOKLYN-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Downer updated BROOKLYN-577:
------------------------------------
Description:
This is an idea for [Google Summer of
Code|https://summerofcode.withgoogle.com/] (GSOC). Potential students, please
read https://brooklyn.apache.org/community/gsoc.html
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.
was:
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.
> 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). Potential students, please
> read https://brooklyn.apache.org/community/gsoc.html
> 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)
