The team discussed the new model and decided to stay with the old model but will implement a new feature where only UCSB employees can see the private APIs, but students can’t see them.
We will create a new security group - employee. When adding accounts we will set the person as an employee or a student.
The API views will be limited to employee role only for private APIs.
If a person is a student and employee, we will set them as employee affiliation and student affiliation.
Christian and Thomas enabled Splunk calls. Thomas promised the separate splunk instance by end of the year.
Diana and Christian met with Tom. He will set up the new instance without moving the history as this is challenging.
We have https://splunkweb2.ets.ucsb.edu available. Tom wants to test with both instances for a week. We need to copy the reports and dashboards. Christian will setup the export to splunk 2. Christian will enable it today. We can verify the results next Thursday. Christian will move all 4 reports and dashboard.
Navodit - Working on the workflow transitions. Learning/using the the original Workflow modules code to pull in the transitions data and filter it. Still needing to determine how to get the correct filtering for display.
During the week, we also discussed that Diana, Navodit and Steven met. During their meeting they decided:
That Diana will review the system once these three things are completed:
The emails/rule transitions are corrected (they were correct at the time of the meeting)
The display values for workflow transitions would be working properly (this is what Navodit is currently working on)
That Navodit will create fake accounts for our end user roles (Developer, Business Approver, and API Administrator) and verify that the system shows the correct state transitions for each role. (to do)
Custom module is pushed to dev instance. Tested with the different roles. Will start to work on the API Publishing view. The workflow status is not showing in the view. Navodit will check all business rules for both workflows and send Diana an email to begin testing.
working on workflow status migration automation. created a feature branch. Roles will be next after the workflow status script.
Migration Process (update new site with data from the current/old site)
Updated to include the API Access / API Publishing Request Workflow History (ie. Audit History)
Updated to include the API Access / API Publishing Request Status values (they changed the format what data is stored in the database between versions)
Updated the workflow processes to better replicate the logic of when to send emails (it looks to be exactly matching the original sites logic now)
Currently looking into a discrepancy in the emails that are sent. In the new system the url to the API Access / API Publishing requests that are included in the email looks like “/node/234”, where it should be “/some-application-name”.
Merged the latest upstream changes into the dev environment.
We changed the workflow for Jira tickets. We are now creating a new multidev environment for each ticket. The multidev environment get’s reviewed and approved before being merged back into the main line.
Navodit will be out on
Steven will be out - , Ian will meet with Navodit during the week (Monday - Thursday, Friday is Caesar Chavez Day)
Navodit finished the Swagger documentation. Yaml file issue - pantheon is not accepting .yml files. It has to be .yaml extension. Pantheon is fixing it but not sure when. We will need to change the extension any time we publish a new API. Navodit is working on ticket 88 - to recreate the API menu.
Navodit will be out 4/30.
Workflow fixes have been completed and are ready for final sign-off.
We are struggling with a password storing problem for the Apigee drupal portal account. The default storage system is not working so Navodit is troubleshooting it. Unfortunately, he doesn’t have access to the drupal portal account password in order to verify his testing.
We sent Navodit the password to the drupal portal account so that he can verify his testing.
If Navodit complete’s the Apigee configuration setup over the next week, he will start work on re-adding the Register and Login buttons.
Our roadmap shows we still have to do: Apigee configuration/integration, Login functionality, conversation about site look & feel redesign, and then the implementation of look & feel.
Our projection is currently for the end of June, but that feels optimistic.
integration with Apigee module is setup, but there is an error getting specific application information. Navodit will create a ticket in GitHub. Steven will submit an apigee ticket. The issue is with old customer accounts. It works fine with a newly created account.
Next - Navodit will sort the API list alphabetically. Login/logout buttons need to be moved to the top bar.
Employee Job API - they have had multiple requests from campus. Created a GraphQL version of it. it is a simpler query language. Implemented a solution for security. client id and secret. get back a job token. can apply row level security. can do column level security as well.
As of , Kevin is looking to build out the Proof-of-Concept around Apigee OAuth for usage on the endpoint by the end of April.
This will include:
An authentication endpoint (which will return JWTs)
.wellknown/openid-configuration endpoint
jwks endpoint
Certificates creation and management
Will test key rotation
Documentation
Reusable Shared Flow for authentication/authorization in Apigee
The expectation is that the standard OAuth/JWT libraries for service providers will be able to use this
The team wants to come up with a unified solution for API security
Kevin is experimenting options without using CAS
2 options
using access token, using custom attributes in the gateway
JWT token, using key value maps, can be encrypted
Christian researched 3rd party oath - OKTA
Apigee cannot communicate with CAS because of a firewall issue
Meet with Noah Baker on
Noah was a little hesitant about putting non-Person objects in CAS
But, he was okay with Services (ie. Applications) in CAS (which allows for OAuth)
By the end of the conversation, he was thinking about seeing if there might be a way to provide the management of CAS Services/Applications through automated means (web apis)
He was also on board with the API Gateway Team moving forward with doing an OAuth Proof-Of-Concept using Apigee as the OAuth provider.
Noah was also questioning if there is a value add in using CAS, if Apigee already provides OAuth services
I sounds like the API Gateway team believes the value add is that the application will be registered in the Campus Identity Systems, and it provides a Campus Provided system for validation/verification on the application servers.
Currently, the API Gateway team can get into the Test CAS Management Portal. This had been setup over a year ago, and Noah was a little surprised by the level of access that was available. Kevin is currently using a Service/Application that was setup for Steven (but really, for the API Gateway team) and is using it to continue Proof-of-Concept work in the future. Potentially, we would explore if the OAuth calls that would go to Apigee could flow through to CAS for authentication.
(See GraphQL section above for notes on Target Dates)
Steven and Seth met with the students. They are continuing to grow the sites. Two new members of the team are taking over. Henry is graduating, Jimmy is staying.
Pending - AWS - migrate the Heroku code and the sql server database
Pending - Account cleanup automation
Pending - Identity integration and automation
Apigee Support
1 FTE on the apigee team to help with student development oversight and support
Now the students have to contact so many groups to have their accounts setup, an FTE can really help with that. Adding the functionality to developer.ucsb.edu to create accounts.
Drupal - OK to work with a student
For other projects like identity account creation and others it will be difficult to work with a student
