WSO2 AI Subscription Portal

[piyumaldk]

Description

In earlier versions of the API Manager and Identity Server releases, the product managed the AI feature's authorization through the onprem keys of Choreo.

For future versions, to correct the design flaws, a new portal has been proposed where administrative users can log in and generate keys. The plan is to deploy the portal for public access. This solution introduces a more user-friendly approach for key generation.

Affected Component

APIM

Version

4.4.0

Related Issues

No response

Suggested Labels

No response

[piyumaldk]

Update on the current state (2024/07/23)

Had a discussion on 2024/07/23 with APIM, IS, and AI team on how to proceed with the task.

Meeting notes:

• Decided that one person from IS side and me from APIM side will work on this for now.

• Decided that we need to further clarify below things in the future

  • Where to put the codebase since both APIM and IS should own the product development?
  • What are the technologies we should use?

• Decided that it's needed to clearly separate task works and one person from IS side and me should discuss and decide that.

• Decided that two issues will be maintained to track this from both teams.

• Decided that both teams should finalise feature requirements and come up with a general requirements list.

[piyumaldk]

Update on the current state (2024/07/25)

Started working on the task from 24th July.

Below are the finalised APIM side requirements (After team discussion)

• Users
  • General users
  • We have to discuss weather there will be paid users in the future

1. General users can log into the subscription portal.

2. After logging into the portal, users will be able to generate a token by providing a unique name. The name should be unique among other tokens created by the same user (e.g., "dev"). Users have a limit of 10 tokens. If a user wants to generate an 11th token, they must remove an existing token.

3. Logged-in users can view previously generated tokens information, which include:

   • Unique name
   • Product
   • Services
   • Created date and expiry time
   • Regenerate button
   • Revoke button
   • Delete button

4. Generated tokens will expire after 2 months (from the date of user creation) for general users, at which point users will not be able to regenerate tokens or create new ones. Paid users do not have such restrictions if we introduce paid users to the portal in the future. In that case, we have to discuss the token expiration method for those users.

5. Once a user generates a token, the token will be visible only at that time, and the UI will inform the user to save the token somewhere safe.

6. Users can log out and will be redirected to the login page.

7. Generated tokens (underneath applications) should have below metadata.

   • User (For possible future use cases for paid users)
   • Unique name or client ID
   • Product
   • Services
   • Created date
   • Expiry date

8. Portal should know if the user logged in is a free user or paid user possibly through a flag, where initial development is only for free users but we have a possibility of improving the product to handle paid users as well to give them access to regenerate tokens.

Below are the requirements cam from IS side

1. User Login

2. Feature Display:

   • User should be able to see all AI features of Product-IS.
   • Descriptions and usage guides for each AI feature.

3. Subscription Management:

   • Users should be able to subscribe to each AI feature individually.
   • Option to manage or cancel subscriptions.
   • Subscription status and history tracking.

4. Key Management:

   • User should get different keys for each AI feature.
   • User should be able to generate, regenerate, and revoke keys.
   • Keys should be securely stored and displayed.

5. UI Display:

   • UI should show the user the following for each AI feature:
   • Key.
   • Other configuration details required for integration with Product-IS.
   • Visual indicators for active/inactive subscriptions.
   • Notifications and alerts for key expiry and subscription updates.

6. User Profile Management:

   • User should be able to update personal information and preferences.
   • Option to view usage reports and analytics.

[piyumaldk]

Update on the current state (2024/07/26)

Discussed the requirements with the person from IS team and agreed on below requirements.

1. Below are the users who will get the access for the portal.

   • General Users
   • Anybody with access to the internet can sign in to the AI Subscription portal.
   • Paid users (In the future)

2. General users can log into the AI Subscription portal.

3. After logging into the portal, users will be able to generate a token by providing a unique name. The name should be unique among other tokens created by the same user (e.g., "dev"). Users have a limit of 10 tokens. If a user wants to generate an 11th token, they must remove an existing token.

4. Logged-in users can view previously generated tokens information, which include:

   • Unique name
   • Description
   • Product
   • Services
   • Created date and expiry time
   • Regenerate button
   • Revoke button
   • Delete button

5. Generated tokens will expire after 2 months (from the date of user creation) for general users, at which point users will not be able to regenerate tokens or create new ones. Paid users do not have such restrictions if we introduce paid users to the portal in the future. In that case, we have to discuss the token expiration method for those users.

6. Once a user generates a token, the token will be visible only at that time, and the UI will inform the user to save the token somewhere safe.

7. Users can log out and will be redirected to the login page.

8. Generated tokens (underneath applications) should have below metadata.

   • User (For possible future use cases for paid users)
   • Unique name or client ID
   • Product
   • Services
   • Created date
   • Expiry date

9. Portal should know if the user logged in is a free user or paid user possibly through a flag, where initial development is only for free users but we have a possibility of improving the product to handle paid users as well to give them access to regenerate tokens.

However, we decided that we will need further discussions on below matters.

1. How to show the generated key? (Only key or whole config)

2. Do we give the access to generate one key for multiple products?

3. How should we handle expired dates?

[piyumaldk]

I did some initial UI sketches like below.

1. 

2. 

3. 

With above UI sketches, I had a discussion with another UI expert and AI expert from APIM team. After some discussions, we agreed on the final UI/UX sketch. It was later introduced to the person who is working from IS team side on this task and he also agreed on the UI/UX design.

Below is the finalised design. (Please note that we yet to have a proper design review on this)

[piyumaldk]

Update on the current state (2024/07/29)

• We had a design review on 2024/07/28 at 1.30PM - SLST (Recording is attached to the event)

• Meeting was 1.30 hours long and discussed from architecture perspective to UX perspective.

• Below are the final conclusions on the UX level.

  • We will remove application terminology and refer them as keys (or Tokens)
  • We will remove service selection and design the tokens to give access to the selected product's all services because otherwise it seems like unnecessary complication.
  • We will switch from the list view to a grid view (with two columns) for bigger screen sizes.
  • We will consider removing and revoking as danger actions and ask users to type something to verify the action.
  • Since paid user handling is not finalised yet, we will later address that and proceed with free users for now. For users, having at least SSO will be ideal. Decided that we need to discuss this more.
  • We need a email service to inform users about expiring tokens.

[piyumaldk]

Update on the current state (2024/08/01)

• A new sketch was designed addressing required changes. This sketch was confirmed by a key person from the last review.

• In next design review, we have to decide on the technologies to use (Since UI sketch is almost finalised). Hence before going for the next design review, I have tried and tested some of the technologies to verify feasibility with the use cases. Below are the current findings.

  • Even though next js is recommended through multiple resources including official React site, we cannot use that because it has a server side and Asgardeo SDK does not support such framework.
  • create-react-app can be used with Asgardeo SDK but there is a possibility of not mainting that project.
  • It was recommended that viteJs will be a proper framework considering the use cases from a Asgardeo expert in a meeting so need to check that feasibility. (If it's fine, we will most probalbly use that react framework)
  • Found an issue on Asgardeo react SDK, and reported it. Eventhough this issue is not a blocker for the development, this is somewhat a limitation.
    • https://github.com/asgardeo/asgardeo-auth-react-sdk/issues/240

[piyumaldk]

Update on the current state (2024/08/05)

• Joined [IAM Engineering] Bi-Weekly UI/UX Design Review in order to get the UI/UX sketches reviewed and to decide the technologies to use.

• Below are the key points from the 2nd (final) design review with IS team

  • To use ViteJS as the react framework.

  • To use Oxygen UI ( Since Oxygen UI was implemented on top of Material UI, in such cases where Oxygen UI cannot accomplished the expected results, I will use Material )

  • To use ESLint with restricted rules to overcome the code quality.

  • Discussed a warning on Oxygen UI ( I was informed that even this comes from Oxygen UI, this comes within Material UI and when Material UI fix this, they will do a major update for Oxygen UI, hence decided to ignore the warning for now)

  • Discussed the UI/UX and since timeline is strict for the project, decided to start implementing without designing Figma and do required changes on top of the code.

  • Please find below finalised design

1. Login Page ( Asgardeo Branding )

2. Landing Page as below

After the review meeting, had another meeting with an APIM UI/UX expert and discussed all the above things and decided to go with decided technologies and designs.

Since the design is finalized, I have shared it in the architecture email thread [1]. (Since we did not receive any feedback via email, we are proceeding with the implementation)

[1] [Architecture][IS] Deployment Architecture for AI Features in Product-IS

[piyumaldk]

Update on the current state (2024/08/09)

Implemented the project with decided technologies for the last four days. For now, project is done in a personal private repo.

• Since backend is not ready, used mockup hardcoded responses for the implementation.

• Finished implementing the decided design of landing page with Asgardeo login (Using React Asgardeo SDK).

• All the requirements in terms of functionality (including danger action validations and tooltips) have been implemented. The remaining tasks are UI/UX improvements.

[piyumaldk]

Update on the current state (2024/09/02)

• Had to move from Asgardeo SDK to Choreo managed authentication using Asgardeo due to a service requirement.

• Deployed the frontend in Choreo using Asgardeo (Managed Authentication)

  • Otherwise, we cannot implement further because whole authentication is only working with the Choreo deployment from now on with these changes.
  • Configure required changes and local deployment and started working on the frontend again.

• Change the authentication from default to sub organisation SSO due to a requirement of the service side implementation.

• Presented the UI, service, and architecture to the AI team and got the feedback [1]

• Implemented micro level details of UI and validations.

• Had 2 offline reviews with UI expert of APIM

• There were some changes required as the authentication flow changed (Due to a limitation on Asgardeo) hence need to change the whole UX/UI flow starting from designs

• Designed new UI / UX and got reviewed them

  • We finally decided to follow the same layout design of Asgardeo login as it will be used for login. (Sign up part will be ours)

  Below are the finalised sketches

Whole UI flow

Implemented those changes with hardcoded responses (Some data structures has been changed due to some blockers form backend side)

[1] https://drive.google.com/file/d/1tt0tQMyVC9ZHBK4NtGiv0_-F4tFQR8AN/view

[piyumaldk]

Update on the current state (2024/09/04)

• Complemented UI/UX implementation (Excluding backend connection)

  • At the time, backend service was not fully completed and deployed, hence implemented with hardcoded response.

• Since, implementation is completed, schedule a UX review (As the final review)

  • Participants : Whole UX/UI team from IS (9 Members) + few from APIM team
  • Please find the 1.30 hour recoding and meeting notes here [1]
  • Number of changes and improvements were suggested after discussion (Listed in the notes)

• Since, implementation is completed, schedule a code review (As project is a product which was written from scratch and contains 37 files)

  • Please find the 1 hour recording and meeting notes here [2]
  • Few changes and improvements were suggested after review (Listed in the notes)

• Got the backend service, hence started connecting the backend again.

  • There were some issues such as different responses to the initial specification which was used for UX/UI implementation, and some of the information were missing.
  • Discuss with the developer and mitigate the issues (Changing the frontend implementation or backend implementation is decided after the discussion for each case)

• Improved error handling and introduced new pages for errors while connecting backend for server level issues.

• As for today, still working on connecting backend and mitigating coming errors as they come.

[1] https://docs.google.com/document/d/1KOu0Y3V4LtctPKwaQieSo8muqqWxpyY8oZCm_kstaQ4/edit?usp=sharing [2] https://docs.google.com/document/d/1YbKspf2kVMSzJqZvx53SxxFtt0CyNqMqnMiOj4KsNI8/edit?usp=sharing

[piyumaldk]

Update on the current state (2024/09/06)

• Completely finished connecting the backend to the portal (Functioning part)

  • As of today, auth sign up service was not completed hence I could not connect that part yet. There were some blockings for the developer who is working on that, and we discussed and found solutions for them. He will keep working on that.

• Because of a limitation on the Asgardeo app, we currently can only generate 2 keys (We have sent a mail to Asgardeo to get the tier increased)

• Tried to merge PR after doing some changes [1], but it seems APIM team does not have write access so informed other developer (Person who asked for the repo creation). He will ask to correctly give the access to relevant teams.

• Since now we have a functioning portal, tried to use APIM AI services using that key.

  • Found out that we cannot use that key as it is. Earlier it was an on-prem key. Now this is a key which can be used to get a token.
  • Discussed the issue with team leads and decided that we have to do some product level changes and interceptor level changes.
  • Currently I'm in the process of studying the current process and the code of APIM and interceptor and working on a solution.

[1] https://github.com/wso2-enterprise/ai-subscription-portal/pull/1