Hey folks,
To test authentication with the new AAA system I'd like to deploy a couple very basic apps that do nothing but auth in staging's openshift. It shouldn't touch any configuration besides the reverse proxies and the new project in openshift. And it's staging only. Is it OK? Thanks.
Aurélien
On Thu, Oct 15, 2020 at 10:32:07AM +0200, Aurelien Bompard wrote:
Hey folks,
To test authentication with the new AAA system I'd like to deploy a couple very basic apps that do nothing but auth in staging's openshift. It shouldn't touch any configuration besides the reverse proxies and the new project in openshift. And it's staging only. Is it OK? Thanks.
Sure, but if you could clean them up afterward that would be good.
kevin
On Thu, Oct 15, 2020 at 10:32:07AM +0200, Aurelien Bompard wrote:
Hey folks,
To test authentication with the new AAA system I'd like to deploy a couple very basic apps that do nothing but auth in staging's openshift. It shouldn't touch any configuration besides the reverse proxies and the new project in openshift. And it's staging only. Is it OK? Thanks.
+1 for me, though I'm not sure I follow the advantage of them over say fedoral, elections or the wiki.
Pierre
Sure, but if you could clean them up afterward that would be good.
Will do, thanks.
+1 for me, though I'm not sure I follow the advantage of them over say fedocal, elections or the wiki.
I could check the features I'm testing independently, such as group membership, agreement signing, user attributes, etc. While apps have a very diverse use of those features, for example with elections I can check my user attributes but the app will only check if I signed the required agreement when I try to vote in a currently active election. If I just install the apps and check that I can log in, I'm afraid I'll miss some of the testing I want to do just because I'm not hitting the right code path.
A.
On Mon, Oct 19, 2020 at 10:34:23AM +0200, Aurelien Bompard wrote:
Sure, but if you could clean them up afterward that would be good.
Will do, thanks.
+1 for me, though I'm not sure I follow the advantage of them over say fedocal, elections or the wiki.
I could check the features I'm testing independently, such as group membership, agreement signing, user attributes, etc. While apps have a very diverse use of those features, for example with elections I can check my user attributes but the app will only check if I signed the required agreement when I try to vote in a currently active election. If I just install the apps and check that I can log in, I'm afraid I'll miss some of the testing I want to do just because I'm not hitting the right code path.
Fair, thanks for the explanation!
Would it be worth keeping this app somewhere to check/debug potential auth issues later then?
Pierre
A little off topic, but Noggin related: I've just (re)created my account on Noggin, since real accounts have not been ported yet, but I'm a bit concerned with this.
Suppose someone move up and would have created an account in Noggin using my username, but using his data... does that mean that they would have access to staging resources my account has access to?
And what about accounts for "VIPs" here that have wide access to the staging infrastructure?
Mattia
On Mon, Oct 19, 2020 at 04:44:34PM +0000, Mattia Verga wrote:
A little off topic, but Noggin related: I've just (re)created my account on Noggin, since real accounts have not been ported yet, but I'm a bit concerned with this.
Suppose someone move up and would have created an account in Noggin using my username, but using his data... does that mean that they would have access to staging resources my account has access to?
yep.
And what about accounts for "VIPs" here that have wide access to the staging infrastructure?
Yes, and no.
I agree it's a concern, and we probibly should disable new accounts in it for now, but it's not a great concern as there's currently no non root ssh access to stg, so no one would get that. They could get access to some apps, but we often sync from prod over staging and anything they do would just be wiped out.
But yeah, I think if the fas sync is going to take a bit, perhaps we should disable the new account creation for now.
kevin
But yeah, I think if the fas sync is going to take a bit, perhaps we should disable the new account creation for now.
I've added the feature to disable registration yesterday, once it's reviewed and merged I'll push it to the staging instance and disable the registration. Thanks for pointing it out.
Aurélien
infrastructure@lists.fedoraproject.org