OOPS - forgot to ask at the end. Are you ok with the plan with this
additional information?
We do need to do some work to implement this — but it is a lot less than
securing the AWS or trying to get Google up and secure.
If everyone is ok - then we need to scope this out - and see just what is
needed and book it.
I will write it up in more detail if this looks good as a general approach -
and we can examine it in more detail.
Let me know
Gregg
GV: see below
> On Jul 8, 2018, at 11:25 PM, Steven Githens <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Gregg,
>
>
>
>> On Jul 5, 2018, at 9:36 PM, Gregg C Vanderheiden <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> that is what I suspected
>>
>> that will give Sergio more time to give notice as well.
>>
>> If I don’t hear anything else by tomorrow - I will proceed with this plan
>> and start them both on the 23rd
>>
>>
>>
>> ALSO - if anyone sees any holes (including you Tyler) in what Tyler and I
>> came up with - and I posted wednesday - as to a plan for going forward with
>> DevOp work and deployment - please send tomorrow (Friday).
>>
>> If I don’t hear anything to the contrary I will move the DevOp & Deployment
>> plan I sent out Wednesday from idea to plan over the weekend as well.
>
> For this, are you referring to the plan that was sent to the UX list last
> week? [1]
>
> I was quite worried about this until I got to the last bullet point that said
> it wasn't for NOVA.
GV: Yeah. This won’t do it all for NOVA. I should have mentioned that earlier
in the plan probably.
> My question is, who is this scenerio for? Internal development and testing?
> Demoing? An AJC? A public library?
GV: It is for the AJC’s and the public library. (Demonstrations don’t need
individual accounts).
>
> If it is for internal testing and demoing it seems fine, but if it's for any
> sort of external use, I think it's going to require quite a lot of extra
> logistics such as:
> - How are these unique usernames and passwords being handed out?
GV: this is being written up for review and Sign off. But basically we
provide the user with a unique name, probably something like User22. And an
easy to type password like “Orange-chair55”
> - How they being generated so people can actually type them? Random
> dictionary concatenation so you get usernames and passwords like
> "strawberry-asphalt-generation" or "incredible-discernment-flower". [2]
GV: yes
> - Since there are no identifiers, there is really no way we could reset
> somebodies password if they lost it, they'd have to start from scratch.
GV: we are also asking for their email - but that information is not stored on
our servers - so our servers do not need to be secure.
> I'm not sure how the offline email strategy below would actually work to
> give someone support if they lost their information. Are the technical
> details written up for that somewhere?
GV: This is being documented. But yes - if we lose the key sheet we will
lose access to their account. So we will have offline backup. Also, all
that is being saved at this point is a small number of settings. So even if
they did lose their PW and we did lose their name - it would take them a
minute or two to set it back up.
As soon as the secure server is set up - we will send them a note to change
their password - and begin using their email (or the user22 if they like) to
sign in.
>
> I have done some work for authenticating cloudsafe usernames and password
> with the Phase II work of the PPT and as part of the preferences server, but
> this approach will still need to be propagated to some other parts of the
> framework, so we should plan that out carefully and inform the architecture
> team about it as soon as possible.
GV: Agree
actually I think the plan is for the PPT to only be available after you sign in
to the Account/CloudSafe — so the login should transfer from the PPT to the
account signin. But check with Bern on the latest plan. this part is not
finalized or signed off on yet.
> While there are some concerns to work out, I think it would be helpful in
> that it would force us to finish and test our cloudsafe login and management
> capabilities, which would actually get us close to being a project that you
> could just clone from github, fire up and run some type of reasonable
> demo/impl of.
Best
gregg
>
>
> Cheers,
> Steve
>
>
>
> [1]
> We already have a working preference server up on Amazon (AWS) that should be
> able to handle traffic at the level we would see in Aug- Sept
> It is not fully secured - and we will not be securing it further (since that
> would majorly distract from the move to the Secure Google implementation
> To avoid the security issues - we provide users with unique SignInNames and
> Passwords of our own creation
> this avoids having any PII like email addresses — and passwords that might
> be used by them elsewhere
> since all we have after that are settings for some already installed apps -
> we won’t have any information that rises to PII that requires more security
> than we have now on AWS
> we can store a key to the SignInNames that links them to email addresses for
> support and lost keys — but that key will not be online anywhere.
> This will allow us to implement both the QSS and the Save functions — while
> we await the secure Google that we will need for NOVA
>
>
>
>>
>>
>> Thanks much
>>
>> Gregg
>>
>>
>>
>>> On Jul 6, 2018, at 12:31 AM, Tyler Roscoe <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> The plan was for them to start at the same time to optimize onboarding, so
>>> I guess they should both start on the 23rd.
>>>
>>> On Thu, Jul 5, 2018 at 10:29 PM, Gregg Vanderheiden GPII <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> One can start next week. Sergio
>>> One can start on 23rd when his current contract runs out Stepan
>>>
>>> Let me know when we should start each of them so that we can write up their
>>> contracts.
>>>
>>> thanks
>>> Gregg
>>>
>>>
>>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.gpii.net/mailman/listinfo/architecture
>> <https://lists.gpii.net/mailman/listinfo/architecture>
>
_______________________________________________
Architecture mailing list
[email protected] <mailto:[email protected]>
https://lists.gpii.net/mailman/listinfo/architecture
<https://lists.gpii.net/mailman/listinfo/architecture>
_______________________________________________
Architecture mailing list
[email protected]
https://lists.gpii.net/mailman/listinfo/architecture
