[katello-devel] Signo integration in CLI and API

Martin Bacovsky mbacovsk at redhat.com
Fri Jun 21 09:34:34 UTC 2013



Dne čtvrtek, 20. června 2013 18:16:51 UTC+2 Eric Helms napsal(a):

    Would you mind including as part of this definitions of the terms
    used in the user stories?


Sure:
  * request - http/https request
  * secret - (similar to token or ticket or key) client ask Signo to 
generate one foer her and it is used to sign the requests to server. 
Server can ask Signo for the same secret assigned to your name and check 
if the requst was signed by the secret (it compares computed signature 
as can be seen on the diagram). User can have more secrets
  * secret expiration - how long the secret remain valid (similar to 
cookie expiration)
Did I miss anything?


    On Thu, Jun 20, 2013 at 12:07 PM, Martin Bacovsky
    <mbac... at redhat.com <javascript:>> wrote:

        I'm working with Marek on integration of Signo in CLI and API.
        As we are building it from scratch we would like to invite
        broader audience for discussion and to help us make it right.

        We have prepared diagram [1] describing the expected
        communication between all the participants.

        Here are user stories  we put together with Marek and Tomas:

        * As a CLI user I would like to use Signo for authentication

    Is a CLI user going to know (or care) what the backend handling
    authorization is? Unless there are other options for the user to
    select what service is handling authentication, this seems like an
    unneeded user story.


Agree, I'll remove it


        * As a CLI user I would like to choose from multiple secrets to
        sign my request
        * As a CLI user I would like to have set the last requested
        secret as a default
        * As a CLI user I would like to set the default secret
        * As a CLI user I would like to see list of my secrets with
        their expiration and issue dates
        * As a CLI user I would like to set expiration in the request
        (e.g. longer for cron jobs)
        * As a CLI user I would like to limit scope of actions the
        secret authorizes me to do


    If I am a CLI user, why would I want to limit what actions I can
    perform on the CLI? Is this something an "admin" would want to
    restrict for users of the system?


The idea behind it is that the secret allows the holder to do things 
under my username. If I e.g. want to have a secret for my cron job to 
sync some content I need the secret to be valid long term and also would 
like to limit the holder to have just necessary subset of my 
permissions. It is for security reasons. But definitely low priority. 
I've seen similar feature on github, where you can issue token for your 
script to access your data on GH, but you can limit it to just some repos.

        * As a CLI user I would like to be able to disable the secret
        * As a CLI user I would like to be able to remove expired secrets
        * As a Signo user I would like to see all my secrets via Web UI
        * As a Signo user I would like to disable particular secret via
        Web UI
        * As a Signo user I would like to create secret via WebUI
        * As a CLI user I would like to use secret created in WebUI
        (sync/store?)

        and last but not least is list of things we need to brainstorm
        first:

        * In CLI how to handle attempt to auth a request with invalid
        cert? (error/try to get new secret)
        * Shouldn't we disable passing passwords as a parameter on
        commandline? What use cases it could brake? UX?
        * How to protect stored secrets on client?

        Comments (especially to unresolved topics) are highly appreciated.

        Cheers,
        Martin


        [1]
        https://github.com/mbacovsky/foreman_cli_draft/tree/master/signo_integration
        <https://github.com/mbacovsky/foreman_cli_draft/tree/master/signo_integration>

        _______________________________________________
        katello-devel mailing list
        katell... at redhat.com <javascript:>
        https://www.redhat.com/mailman/listinfo/katello-devel
        <https://www.redhat.com/mailman/listinfo/katello-devel>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/katello-devel/attachments/20130621/2c4ab504/attachment.htm>


More information about the katello-devel mailing list