Would you mind including as part of this definitions of the terms used in
the user stories?
> 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.
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?
···
On Thu, Jun 20, 2013 at 12:07 PM, Martin Bacovsky wrote:
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.
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?
>
>> 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.
···
> On Thu, Jun 20, 2013 at 12:07 PM, Martin Bacovsky <mbac...@redhat.com > > wrote:
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.
