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

[Feat] OIDC Provider staff panel for testing a RP #72

Open
peppelinux opened this issue Mar 7, 2022 · 3 comments
Open

[Feat] OIDC Provider staff panel for testing a RP #72

peppelinux opened this issue Mar 7, 2022 · 3 comments
Assignees
Labels

Comments

@peppelinux
Copy link
Member

if a user gets logged in and he is a staff (user.is_staff == True) we MUST redirect the user to the testing page instead of the consent one.

In the testing page the user (staff) can select one of the several test we'll have to check the compliances of a RP to SPID and/or CIE id.

the user can also be able to change the attributes, remove or add, to be released to the RPs.

@peppelinux peppelinux added the core label Mar 7, 2022
@peppelinux peppelinux added this to the 0.5.0 milestone Mar 7, 2022
@peppelinux peppelinux changed the title [Feat] OIDC Provider staff panel for testing an RP [Feat] OIDC Provider staff panel for testing a RP Mar 7, 2022
@peppelinux peppelinux self-assigned this Mar 14, 2022
@peppelinux peppelinux modified the milestones: 0.5.0, 0.6.0 Mar 16, 2022
@peppelinux
Copy link
Member Author

We have this here
image

@dezhizhang1985 please add a concrete navbar with history page of user accesses

The application where to develop this feature is relying_party_test.

Then we need a django global settings dictionary, fullfilled of packages-as-string (dynamically importables), each package has a function with a common name and a common set of kwargs. Each function returns the issued tokens and also the authz code, all in.

When a staff user comes in the test page here we have to get OR create all the available tests (take from that setting dict) FROM/TO here.

If a test is already done, we'll represent the status. If not we create it without a status.

All the tests are now represented to the staff user. He can checks the status of these and run these again, using the current session (using your browser) or via batch. The only way to have tests via batch is if the RP support a public url where to trigger the authz request to a provider.

Va batch the code would be similar to this, using an embedded chrome browser that can take screenshots

import asyncio
from pyppeteer import launch

async def main():
    browser = await launch()
    page = await browser.newPage()
    await page.goto('https://example.com')
    await page.screenshot({'path': 'example.png'})
    await browser.close()

asyncio.get_event_loop().run_until_complete(main())

pointing and clicking via web we also need a bunch of js lines of code that inspect the values of these DOM input fields

id_redirect_uri
id_attributes
id_authz_url

and also the id of the pressed button (that has the id of the test), via POST.
the view that receives this POST is protected with request.user.is_authenticated (if the user is testing with its browser) or with a StaffAuthzToken (for batch needs or for a js that call this resource under the hood).

If batch the view will execute the embedded browser starting from the authz url of the RP, collects http status code and takes a screeshot.

If browser the operator will check by hands and will mark the test as failed.

@peppelinux
Copy link
Member Author

SPID/CIE QaD tests

Once the submission passes the initial checks the request is saved and a batch will start the
Automatic checks on the latter new registered entity. These check covers

  • entity configuration:

    • reachability
    • signature validation
    • best practices checks following AgID and IPZS OIDC Fed guidelines.
  • RP authz check following AgID and IPZS OIDC Fed guidelines.

  • trust marks forgery (if present for recurrent sample checks)

The tests produces a json report.
this report would be also available in HTML format.

Considerations

  1. it would be necessary to "regulate" how the entities must expose a trigger url of the authn request.
    This would allow us to batch automate testing and obtain asynchronous reports and request states.
    Automatically a warning email would be sent to users.

  2. It would be useful to standardize a "quota" to avoid that "the usual primers"
    can make too many stupid requests all at once, that is, max N batch testing can be performed per day for a single applicant.

@peppelinux
Copy link
Member Author

This feature will be developed by AgID so this issue is on hold untill we don't get a clear plan

@peppelinux peppelinux removed this from the 0.6.0 milestone Mar 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants