Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port relevant applications over to fasjson #4

Open
sfinn85 opened this issue Dec 23, 2019 · 15 comments
Open

Port relevant applications over to fasjson #4

sfinn85 opened this issue Dec 23, 2019 · 15 comments
Labels
L
Projects

Comments

@sfinn85
Copy link

@sfinn85 sfinn85 commented Dec 23, 2019

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 comment has been minimized.

Copy link
Member

@puiterwijk puiterwijk commented Jan 6, 2020

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

@puiterwijk puiterwijk transferred this issue from fedora-infra/freeipa-fas Jan 6, 2020
@relrod relrod changed the title Port them over to view Json Port relevant applications over to new readonly JSON API. Jan 17, 2020
@sfinn85

This comment has been minimized.

Copy link
Author

@sfinn85 sfinn85 commented Jan 21, 2020

@relrod

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

@abompard

This comment has been minimized.

Copy link
Member

@abompard abompard commented Jan 30, 2020

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

@relrod

This comment has been minimized.

Copy link
Member

@relrod relrod commented Feb 3, 2020

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.

@abompard abompard self-assigned this Feb 5, 2020
@sfinn85

This comment has been minimized.

Copy link
Author

@sfinn85 sfinn85 commented Feb 6, 2020

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

@abompard abompard transferred this issue from fedora-infra/securitas Feb 6, 2020
@abompard abompard changed the title Port relevant applications over to new readonly JSON API. Port relevant applications over to fasjson Feb 6, 2020
@abompard

This comment has been minimized.

Copy link
Member

@abompard abompard commented Feb 6, 2020

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.

@abompard abompard added the L label Feb 6, 2020
@abompard abompard removed their assignment Feb 6, 2020
@abompard abompard moved this from Backlog to To do in AAA Feb 6, 2020
@sfinn85 sfinn85 moved this from To do to Backlog in AAA Feb 7, 2020
@sfinn85 sfinn85 moved this from Backlog to To do in AAA Feb 7, 2020
@tiran

This comment has been minimized.

Copy link
Contributor

@tiran tiran commented Feb 10, 2020

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

This comment has been minimized.

Copy link
Member

@abompard abompard commented Feb 10, 2020

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

This comment has been minimized.

Copy link
Contributor

@tiran tiran commented Feb 10, 2020

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 ryanlerch moved this from To do to In progress in AAA Feb 11, 2020
@ryanlerch ryanlerch moved this from In progress to To do in AAA Feb 11, 2020
@ryanlerch

This comment has been minimized.

Copy link

@ryanlerch ryanlerch commented Feb 11, 2020

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

This comment has been minimized.

Copy link

@ryanlerch ryanlerch commented Feb 11, 2020

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

This comment has been minimized.

Copy link
Member

@puiterwijk puiterwijk commented Feb 11, 2020

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

This comment has been minimized.

Copy link
Member

@abompard abompard commented Feb 11, 2020

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 sfinn85 moved this from To do to Backlog in AAA Feb 19, 2020
@sfinn85

This comment has been minimized.

Copy link
Author

@sfinn85 sfinn85 commented Feb 19, 2020

1 spike
2 large
3 large
4 large

@abompard

This comment has been minimized.

Copy link
Member

@abompard abompard commented Feb 21, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
AAA
  
Backlog
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.