Hi Silvano, in-line;
On 12-Aug-2014, at 11:50 pm, Silvano Nogueira Buback <silv...@corp.globo.com> wrote: > 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 I agree, you may want a different URL path in which case it makes sense to implement your own Servlet or when such a situation comes we can try if any refactoring can support old and new mechanisms. > 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]. Yes, I’ve looked at Spring security and it was not pleasure to work with it. > 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). Right now, we assume and check by command (name) and break when we find a class that handles that command. But, sure we can do that but I’m interested only when we’ve something to implement that would consume this design instead of going around abstracting things which we may not even use. > 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. Sure. > 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. This would be tricky and not scalable (I would prefer statelessness, and not having to burden JVM heaps). But that would work as well using some context/registry store. > 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. If it does not take much time, go ahead and implement something (proof of concept) in your fork that I can play with too. If it’s useful we’ll get that in ACS as well and I can help you with reviewing and merging your stuff into ACS. Cheers. > > 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 <create...@me.com> wrote: > >> >> >>> On Aug 12, 2014, at 5:12 AM, Adrian Lewis <adr...@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.ya...@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.tur...@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.ya...@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.ya...@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.ya...@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.ya...@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.
