Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of silvano@corp.globo.com
 designates 74.125.149.205 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <AB24A1E8-FB9F-4389-B8ED-3E13BB8B457B@me.com>
References: <AB2E274A-DEEA-40E9-937A-9A3A7C71B65C@shapeblue.com>
 <85B56B1AEDD2674A82DEC8B61E1218294208C1@AMSPEX01CL01.citrite.net>
 <31F89D57-DBA8-4EC9-B9BD-B641805F784A@shapeblue.com>
 <360a49dff74b04ab81bbf83dc6820092@mail.gmail.com>
 <AB24A1E8-FB9F-4389-B8ED-3E13BB8B457B@me.com>
From: Silvano Nogueira Buback <silvano@corp.globo.com>
Date: Tue, 12 Aug 2014 18:50:02 -0300
Message-ID: 
 <CA+rXN7-2uUoJ+on++7e6Q8WNR2mppgVfuPT-_YMaN464+1riYQ@mail.gmail.com>
Subject: Re: [SHOW] Authentication refactoring
To: dev@cloudstack.apache.org
Content-Type: multipart/alternative; boundary=089e0149c59485d666050075a8a1

--089e0149c59485d666050075a8a1
Content-Type: text/plain; charset=UTF-8

Rohit,

    When I started implementing OAuth2 integration I faced this problem,
but I had other things to do first, now I am back to this problem too. I
took a look at your implementation and it's almost fit for OAuth2. I have a
few comments:

Some authentication mechanisms may not work as a command. I proposed to use
commands to implement OAuth2 to not change ApiServlet (before knowing the
real problem with unauthenticated command), but I think this is not a good
implementation (for OAuth2). If the idea is to refactor to support multiple
authentication mechanisms, maybe a filter can be better. Take a look in
Spring Security implementation [1].

So, using your implementation, I would suggest:

   1. When a new request arrives, If user is not authenticated,
   APIAuthenticatorManager is called and should iterate over all
   APIAuthenticator instances, one by one, in the order specified by
   user.authenticators.order global setting (do not forget this, please).
   1. In each APIAuthenticator, it can analyze the HttpRequest and if it
      should authenticate, it must return an UserAccount object. If the
      authenticator doesn't  authenticate it raises some exception like Spring
      does.
      2. As all existed authenticators inheriting today
      from DefaultUserAuthenticator, this authenticator can implement the
      APIAuthenticator interface and if there is a parameter with
command=login,
      username, password the abstract method "authenticate"
      from UserAuthenticator must be called. So, all existing authentication
      mechanisms will work as today, respecting the order
      from user.authenticators.order global setting.
   2. After authentication, the name of the APIAuthenticator that
   authenticated must be kept in session. User, and other objects must be kept
   as well. In logout, the APIAuthenticator used can be called.
   3. When a new request arrives, if user is authenticated, it works as
   today.


    If everybody agrees on the solution I can work together with you to
finish this if you want. I need to finish OAuth2 integration in the next 15
days... and I don't want to change my implementation later on.

    If it's possible to work together, we need do this in a separated fork
of ACS, since I'm not a committer yet.

Regards,

Silvano Buback
[1]
http://docs.spring.io/spring-security/site/docs/3.2.4.RELEASE/apidocs/org/springframework/security/web/authentication/AbstractAuthenticationProcessingFilter.html


On Tue, Aug 12, 2014 at 11:20 AM, Carlos Reategui <creategui@me.com> wrote:

>
>
> > On Aug 12, 2014, at 5:12 AM, Adrian Lewis <adrian@alsiconsulting.co.uk>
> wrote:
> >
> > Hi Rohit,
> >
> > Not a very constructive email I'm afraid but I too would be very
> > interested in one-time password authentication for CS. Is anyone that you
> > know of working on RADIUS auth as this would be a relatively easy way to
> > integrate a wide number of OTP systems that rely on a secondary auth
> > challenge for the OTP. This secondary auth mechanism is part of the
> RADIUS
> > standard and would cover RSA as well as the system that I'm interested in
> > implementing (Fortinet's FortiAuthenticator) and many other
> > enterprise-focussed OTP systems.
> >
> > Not sure if OTP/2FA would be suitable for API access so a second question
> > is: Would it be feasible to use different auth backends for the GUI vs
> the
> > API? As I understand it, the GUI is simply a 'wrapper' for the API so
> > perhaps not but I'm sure I'm not alone here in wanting OTP/2FA, perhaps
> > even at the expense of API access. Contrary to popular belief within the
> > CS community, not everyone uses the API (shock horror!). Maybe OTP/2FA is
> > not an issue for API access but I assume it would be a problem for the
> use
> > of Puppet/Ansible/Salt etc. Perhaps a source IP ACL so that only
> specified
> > IPs can use a standard auth method but all other access mandates OTP/2FA?
> > Not sure how AWS works with their MFA feature - anyone?
> MFA is used for accessing UI console where you manage your keys for API
> usage.
> API access is controlled via IAM or key/secret which you manage from the UI
> >
> > I'm afraid I'm just a (ab)user and couldn't program anything myself -
> just
> > curious to see if anyone has any thoughts or existing efforts in this
> > area?
> >
> > Cheers,
> >
> > Adrian
> >
> > -----Original Message-----
> > From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> > Sent: 12 August 2014 11:41
> > To: dev@cloudstack.apache.org
> > Subject: Re: [SHOW] Authentication refactoring
> >
> > From the user end there is no change, not in UI or any change expected in
> > clients except one:
> > Since login and logout are now implemented like your regular api, we
> don't
> > allow uses to call login and logout and other such AuthenticatorAPIs
> > directly like via integration port
> >
> > Stephen, I'm not sure if we natively support RSA and other things at
> > present we only have our custom login auth mechanism, signature/key based
> > auth and a simple SSO (pre-shared key) methods. This refactoring will
> open
> > doors for saml, oauth and possibly others.
> >
> > This is merged on master now, even though I did testing at my end please
> > let me know if something got broke? From the outside world nothing should
> > break, i.e. refactoring.
> >
> > Cheers.
> >
> > On 12-Aug-2014, at 12:32 pm, Stephen Turner <Stephen.Turner@citrix.com>
> > wrote:
> >
> >> Are there any UI changes? Some auth mechanisms might need more than just
> > username and password (RSA token, for example, or even just "give the
> 1st,
> > 4th and 5th characters").
> >>
> >> --
> >> Stephen Turner
> >>
> >>
> >> -----Original Message-----
> >> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> >> Sent: 12 August 2014 04:51
> >> To: dev
> >> Subject: [SHOW] Authentication refactoring
> >>
> >> Hi,
> >>
> >> The way we handle login and logout is hardcoded and since there is no
> > APICommand/BaseCmd implementation the apidoc, apidiscovery and other
> don't
> > discover these apis. For supporting SAML as an authentication mechanism,
> > I've refactored the Auth mechanism as a pluggable service that loads with
> > api-server artifact and both login and logout are now implemented as a
> > pseduo BaseCmd classes.
> >>
> >> I call them pseudo because their execute() is never called, the
> > authentication guards in ApiServlet class make sure we call an
> > authenticate method of such classes. Since, they are tightly coupled with
> > cloud-server's ApiServlet it only made sense to have the interface
> > definition and implementation within the same package/artifact as well.
> > This also solves the apidoc issue for login/logout and saml related auth
> > apis.
> >>
> >> I'll merge them after sometime and continue working on saml stuff. Will
> > push the code in the branch "auth-refactor" in an hour for review/testing
> > now. This does not break anything and should not cause any auth related
> > issues for all existing clients.
> >>
> >> Any suggestions, feedback welcome! Refactoring was pretty straight
> > forward but I'll make sure to write a wiki page on this before merging to
> > master.
> >>
> >> Regards,
> >> Rohit Yadav
> >> Software Architect, ShapeBlue
> >> M. +41 779015219 | rohit.yadav@shapeblue.com
> >> Blog: bhaisaab.org | Twitter: @_bhaisaab
> >>
> >>
> >>
> >> Find out more about ShapeBlue and our range of CloudStack related
> > services
> >>
> >> IaaS Cloud Design &
> > Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> >> CSForge - rapid IaaS deployment framework<http://shapeblue.com/csforge/
> >
> >> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> >> CloudStack Infrastructure
> > Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> >> CloudStack Bootcamp Training
> > Courses<http://shapeblue.com/cloudstack-training/>
> >>
> >> This email and any attachments to it may be confidential and are
> > intended solely for the use of the individual to whom it is addressed.
> Any
> > views or opinions expressed are solely those of the author and do not
> > necessarily represent those of Shape Blue Ltd or related companies. If
> you
> > are not the intended recipient of this email, you must neither take any
> > action based upon its contents, nor copy or show it to anyone. Please
> > contact the sender if you believe you have received this email in error.
> > Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> > Services India LLP is a company incorporated in India and is operated
> > under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
> a
> > company incorporated in Brasil and is operated under license from Shape
> > Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
> > South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
> is
> > a registered trademark.
> >
> > Regards,
> > Rohit Yadav
> > Software Architect, ShapeBlue
> > M. +41 779015219 | rohit.yadav@shapeblue.com
> > Blog: bhaisaab.org | Twitter: @_bhaisaab
> >
> >
> >
> > Find out more about ShapeBlue and our range of CloudStack related
> services
> >
> > IaaS Cloud Design &
> > Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> > CSForge - rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> > CloudStack Infrastructure
> > Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> > CloudStack Bootcamp Training
> > Courses<http://shapeblue.com/cloudstack-training/>
> >
> > This email and any attachments to it may be confidential and are intended
> > solely for the use of the individual to whom it is addressed. Any views
> or
> > opinions expressed are solely those of the author and do not necessarily
> > represent those of Shape Blue Ltd or related companies. If you are not
> the
> > intended recipient of this email, you must neither take any action based
> > upon its contents, nor copy or show it to anyone. Please contact the
> > sender if you believe you have received this email in error. Shape Blue
> > Ltd is a company incorporated in England & Wales. ShapeBlue Services
> India
> > LLP is a company incorporated in India and is operated under license from
> > Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company
> > incorporated in Brasil and is operated under license from Shape Blue Ltd.
> > ShapeBlue SA Pty Ltd is a company registered by The Republic of South
> > Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a
> > registered trademark.
>

--089e0149c59485d666050075a8a1--