----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16710/#review31847 -----------------------------------------------------------
I am not a big fan of this approach because, I see the following issues: (a) This implementation assumes that the auth mechanism can be verified from the host the scheduler is deployed. Auth may not be implemented this way at other places or the scheduler may not have required resources to perform the auth. (b) Even while keeping the auth mechanisms separate, this approach bakes the auth mechanism into the scheduler code base. (c) it skews the metrics like the amount of time it takes to process a request because the auth may take variable amount of time. I think delegating the auth to a set of trusted proxies or clients, while keeping a simple auth checks inside the scheduler may be a better way to implement this. PS: I may have understood this entirely wrong, if so, please feel free to ignore this. - Suman Karumuri On Jan. 8, 2014, 12:45 a.m., Kevin Sweeney wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/16710/ > ----------------------------------------------------------- > > (Updated Jan. 8, 2014, 12:45 a.m.) > > > Review request for Aurora, Suman Karumuri, Maxim Khutornenko, Bill Farner, > and Brian Wickman. > > > Repository: aurora > > > Description > ------- > > Support multiple simultaneous auth mechanisms. > > Currently the SessionKey thrift struct has a mechanism field that the > scheduler ignores. This change would make the scheduler enforce usage of this > field and dispatch the choice of auth mechanism to an > appropriately-registered handler. This change also adds a handler registry > (via a MapBinder) to allow for independent auth subsystems to register > without knowledge of each other. For example, an LDAP_SIMPLE_BIND mechanism > might contact an SSO server and be used by human users while an OAUTH2 > mechanism might be used by another service to perform automated quota > management. Each of these subsystems could be enabled and configured > independently and would coexist on the same cluster. > > > Diffs > ----- > > src/main/java/org/apache/aurora/auth/UnsecureAuthModule.java > 0248c95745fb49f92c1b0db08b878adf9f863a3f > src/main/java/org/apache/aurora/scheduler/app/SchedulerMain.java > c69a2a6c57139f0ad27b1084a24354b80d2465c6 > > src/main/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterface.java > c1a11bdb91c5e764864324d26248d1783af8048b > src/main/java/org/apache/aurora/scheduler/thrift/aop/AopModule.java > 7c29094c138238ddf0d34d9f795b8aea8f17b421 > src/main/java/org/apache/aurora/scheduler/thrift/aop/Interceptors.java > ee22af10a469db1a3cc46d9092285977b5526f9e > > src/main/java/org/apache/aurora/scheduler/thrift/aop/LoggingInterceptor.java > e66a885302c492b9669e9b526edd7f3c2e9f3ef7 > > src/main/java/org/apache/aurora/scheduler/thrift/aop/SessionKeyMechanismInterceptor.java > PRE-CREATION > > src/main/java/org/apache/aurora/scheduler/thrift/aop/UserCapabilityInterceptor.java > 8e6e52d6418f5e6809f21b7ab83e6ead0f29be19 > src/main/java/org/apache/aurora/scheduler/thrift/auth/ThriftAuthModule.java > 1de64bc608d7e0191f81986166504a182374ada9 > > src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java > 91c1c24448092e1b3454844ab8074ed030383594 > src/test/java/org/apache/aurora/scheduler/thrift/ThriftIT.java > cce27a0e37452f370a3729b6b05bf0bea29f85f6 > src/test/java/org/apache/aurora/scheduler/thrift/aop/AopModuleTest.java > b510bf1222961329c4eae0a17ff0dfb274ee55a8 > > Diff: https://reviews.apache.org/r/16710/diff/ > > > Testing > ------- > > ./gradlew build > > > Thanks, > > Kevin Sweeney > >
