[ https://issues.apache.org/jira/browse/BROOKLYN-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16348648#comment-16348648 ]
Geoff Macartney commented on BROOKLYN-577: ------------------------------------------ Re. password expiry, let's take account of recent thinking on auth such as [https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/] and take some care not to impose restrictions on passwords that are maybe not best practice any more. Also re. notion of tokens for auth, again let's think carefully - tokens are great for some use cases but not necessarily for sessions, e.g. [http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/], at least we need to be able to invalidate a compromised token without any delay. > 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)