72 lines
2.4 KiB
Org Mode
72 lines
2.4 KiB
Org Mode
#+Title:Cisco Epic Feature Flag by Env
|
|
#+Author: Yann Esposito
|
|
#+LANGUAGE: en
|
|
#+TODO: TODO IN-PROGRESS WAIT | DONE CANCELED
|
|
|
|
* Feature Flag by Env :TOC_3_gh:QUOTE:
|
|
#+BEGIN_QUOTE
|
|
- [[#requirement][Requirement]]
|
|
- [[#current-status][Current status]]
|
|
- [[#proposed-solution][Proposed Solution.]]
|
|
- [[#feature-flag-block-in-configedn][Feature Flag Block in =config.edn=]]
|
|
#+END_QUOTE
|
|
|
|
** Requirement
|
|
|
|
> Craig Brozefsky Yesterday, 17:04
|
|
> Matt: No orgs in EU should have devices scope
|
|
|
|
*** Current status
|
|
|
|
Until now we managed feature flag for an entire release. As such the
|
|
feature-flag was 100% held in the code, not in the deployement conf.
|
|
|
|
There are two methods used until today to manage feature-flags:
|
|
|
|
1. scopes
|
|
2. service launch (in bootstrap.cfg)
|
|
3. control via config (in config.edn)
|
|
|
|
The current requirement only talks about the =sse= scope.
|
|
In fact we could (should) also prevent the =sse-service= to be launched.
|
|
|
|
Note that scope handling is generally not trivial:
|
|
|
|
- CTR use the scope as the single dimension to handle authorizations. One
|
|
consequence is that the notion of /role/ is not really meaningful in the CTR
|
|
code. The /role/ is only used from the info provided by the IdP and then
|
|
interpreted as a set of scopes (which can change dynamically, for exemple we
|
|
can attribute additional scopes to some org or user). It is also planned to
|
|
provide the ability for admin users to change the scopes of other users of
|
|
their org.
|
|
|
|
** Proposed Solution.
|
|
|
|
*** Feature Flag Block in =config.edn=
|
|
|
|
That way it would be possible to not only handle scopes but also manage the
|
|
feature flag in some specific part of the code. Typically we could use that flag
|
|
to ignore some conf, and to not initialize fully some service.
|
|
|
|
**** Service Launch Handling
|
|
|
|
- If a service is started but its presence is not necessary when the feature
|
|
flag is off. The service should not really init itself fully and only return a
|
|
nil context and the methods should also returns nil silently
|
|
|
|
**** Scope Handling
|
|
|
|
Depending of the feature flag we might add an additional step during login we
|
|
might "add" some new scopes and "remove some". If that's the case we might also
|
|
change the JWT version dyamically.
|
|
|
|
I would suggest something like:
|
|
|
|
|
|
#+BEGIN_SRC clojure
|
|
(defn dyn-jwt-version [activated-features]
|
|
(string/join "-" (cons static-jwt-version activated-features))
|
|
#+END_SRC
|
|
|
|
That would produce version such as: =v1.23=, =v1.23-sse=, =v1.23-sse-scim=,
|
|
etc...
|