Port relevant applications over to fasjson

[sfinn85]

The current FAS has an read-only API that some of the Fedora applications use. These applications include zodbot and the sigul bridge.

In the new freeIPA / secuiritas world, such applications will interact with fasjson (https://github.com/fedora-infra/fasjson).

This ticket is to track the porting of these applications over to the new fasjson API

(description updated based on @relrod comment below -- https://github.com/fedora-infra/securitas/issues/56#issuecomment-581444027 )

[puiterwijk]

This issue makes no sense.
Can we get any more information?

[sfinn85]

@relrod

I don't have access to pull this over, in our to do lane on AAA. Can you do this?

[abompard]

I'm not sure what to do here, could we have more details please?

[relrod]

We need to stand up fasjson (https://github.com/fedora-infra/fasjson) and test porting our apps that use the current FAS API to it. This includes things like zodbot (supybot-fedora), sigul bridge (checks to make sure user is in the signers group), etc.

In pretty much every case, the apps are just doing simple read-only checks against the API which fasjson is built for. So the apps need to point to fasjson instead and do those read-only checks against it instead of FAS.

[sfinn85]

Breakin this down into other user stories see links . @abompard to add user stories ( Issues )

[abompard]

We need to build an exhaustive list of applications that use the FAS API. Then, for each of those apps, we need to start a local instance with the configuration pointing at the fasjson instance that we will have available thanks to #3, and make sure they keep working properly.

Acceptance criteria:

• Every app using the FAS API has been identified
• Local instances of those apps configured to use fasjson keep working when they need to query FAS
• The data returned by fasjson is what the app expected.

DoD: all of the above are met.

[tiran]

Before you port your applications, please compile a list of requirements. The fasjson code is a demo (aka quick hack). I literally spent less than 10 minutes to come up with the JSON response. At a bare minimum we should come up with a versioning scheme and proper error codes.

[abompard]

If I understand correctly, the point of fasjson is to mimic the current FAS API but getting data from LDAP. Was that not what you had in mind when you wrote it @tiran

Note to @sfinn85 : we need to schedule some User Stories to check that the code actually mimics what FAS currently returns, before we port applications to it.

[tiran]

The fasjson API is loosely based on the technical requirements specification from meetings between CPE and IPA managers and engineers. The implementation is a proof of concept (and even documented as PoC).

[ryanlerch]

Okay, so the first item in the Acceptance Criteria is a good starting point for formulating some more formal requirements. What is actually using the current FAS API?

I have made a wikipage here to try to make a list, and have added the two mentioned in this thread, supybot-fedora and sigul. https://github.com/fedora-infra/fasjson/wiki

[ryanlerch]

Just wondering what the best approach to this is.

Would the better approach be to keep the fasjson api simple (the current FAS one is far from simple), and then when porting the applications over, no use the python-fedora module at all?

[puiterwijk]

So, I think we should stop using python-fedora for this, since this API should be restricted, in that it's only available for the applications that we know of.
This also comes back in the fact that this uses GSSAPI to authenticate, and then the IPA ACLs to determine which details an application can retrieve about users.

I think we explicitly do not want to offer an API to any random person/app on the internet, given that they can then scrape all of the account data.

Given that, I think we should no longer use python-fedora, or at least put it in a new module in that repo, to indicate that this has an entirely different use.

Applications can still use SAML2 or OpenID (Connect) to get information about the user that's currently using that app.

[abompard]

OK, so the plan is not for fasjson to mimic the FAS API, but to have its own specific API and port applications over to it, correct?

Therefore we need to :

• take some time to think about API design
• implement it in fasjson
• create a client library in python if useful (even a simple one that wraps requests would be nice)
• port applications over to it.

Does this make sense?

[sfinn85]

1 spike
2 large
3 large
4 large

[abompard]

This has been split off in #6, #7, #8, #9 and #10 .