To start off, our first print went very well. Our project for this class is
the LibreFoodPantry Identity and Access Management System. Our main goal in
this sprint was to get familiar with Keycloak and learn how to implement it and
also building a small API. The issue that was created for Keycloak and what I
did researches on are “Keycloak authentication”, which had a weight
of two and “Deploying Keycloak on AWS Kubernetes” which had a weight
of two as well based on the time it took to do research and find good resources
to help us move forward with our projects.

In our team, we decided to divide and separate tasks. It was actually a way
for us to do multiple tasks at the same time and go forward with the plan. So,
Mike and Lena started working with frontend and backend, then with API after,
George who was the scrum master, took care of managing everything, handling the
whole group, creating documents. I and Andrew did researches on Keycloak and how
to implement it. Even though we all had our tasks to do, we were also able to
help others in case of need.

Doing research seems an easy task, but in reality, it is not. When I started
first doing research on Keycloak authentication, I had a lot of different links
but it was hard for me to find one that had the exact information that me and
the group were looking for. Not saying that there were no good links but Keycloak
is pretty broad and I had to do a lot of research and dig in to find good ones.
One of my mistakes here was that I was trying to find good links, good articles
and completely neglected the side of watching videos. Then, with a couple of
videos I have been able to understand and find good resources that I shared
with the group.

Looking to my personal achievement and work, I want to improve the way I
share my thoughts with the team. I barely created issues during the first
sprint planning, and was not really involved in sharing my ideas and opinions. I was
contributing to the conversations but never putting anything visual on GitLab
as a proof of my contribution. So, for the next sprint, I decided that I will
be more involved and put up my work to show my contribution to the group.

Looking at the team work, we did an amazing job working together on our
first sprint. We all listened to each other, everyone felt comfortable talking
and sharing their ideas. Also, everyone put a good effort and got the work
done. But one thing I think we need to work more on is the communication among
us out of class. Having a little time of communication did not make the first
sprint planning easy. We were all working on our tasks and talking about it
just in class either on Mondays and Wednesdays. So, organizing ourselves and
try to find a time for all of us that works and schedule weekly meetings out of the
class so we can talk more about the project, our tasks and express whatever
thoughts, opinions and questions we have at the moment will be very helpful. And, we
can meet via zoom or discord voice channels and talk more about the project.

The two issues that I worked on:

Keycloak authentication: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/1

Deploying Keycloak on AWS Kubernetes: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/5

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

During Sprint Retrospective 6 I continued to learn more about the CryptoJS library, encryption, Angular, and Git. From the CryptoJS npm page, this code snippet helped me understand how data is encrypted and decrypted using the CryptoJS library:

var CryptoJS = require("crypto-js");
 
var data = [{id: 1}, {id: 2}]
 
// Encrypt
var ciphertext = CryptoJS.AES.encrypt(JSON.stringify(data), 'secret key 123');
 
// Decrypt
var bytes  = CryptoJS.AES.decrypt(ciphertext.toString(), 'secret key 123');
var decryptedData = JSON.parse(bytes.toString(CryptoJS.enc.Utf8));
 
console.log(decryptedData);

My job on the team was to implement a function to encrypt a data record, I also added the decryption function as they go hand-in-hand. The example shown above is in Javascript but easily implemented them into a Typescript file. The following are the functions I came up with in my encryption / decryption service file:

Encrypt a Record

public encryptRecord(data: any[], privateKey: string) : string{
    let ciphertext = CryptoJS.AES.encrypt(JSON.stringify(data), privateKey);
    return ciphertext;
}

This function takes a set of data, and a given private key, encrypts the data, and returns and the encrypted string.

Decrypt a Record

public decryptRecord(ciphertext: string, privateKey: string) : string{
    let bytes  = CryptoJS.AES.decrypt(ciphertext.toString(), privateKey);
    let decryptedData = JSON.parse(bytes.toString(CryptoJS.enc.Utf8));
    return decryptedData;
}

This function takes the encrypted string, and a private key and returns the decrypted string.

I learned a lot of information about Typescript and web applications, I learned more about Node.js, encryption, and Javascript. I feel this information will help me in my professional career, especially if I am working with web development and API’s. I am interesting in further contributing to this open source project, and possibly more. I would like to improve my skills in Javascript and Angular. I would like to learn more about Angular testing and continue to work on the tests I wrote for my functions, to make sure they are working properly.

The team was successful in finding a suitable cryptography library that had all the features we were looking for, but we did run into trouble getting CryptoJS implemented in the ampath application. I successfully implemented the features for encrypting and decrypting a data record, hopefully it will be used to help future teams encrypt patient data. I think I spent too much time researching and not enough time actually working with the ampath application. I did find though that the solution I needed was easier that I thought it would be. We all hit some roadblocks getting things to always work, sometimes the ampath application would give us compilation errors out of nowhere.

During this Sprint we continued working on our respective parts of the encryption service. I successfully wrote two functions, one to encrypt a data record and one to decrypt a data record. I wrote test files for the functions that I believe will work but had some trouble getting the tests to work. Once we made the decision to use CryptoJS, I used this source to help me contribute my part to the project. I pushed my part of the project to my local repository and then made a pull request for the group repository. I did have some trouble with Git dealing with merge conflicts and setting the remote, but feel I was due for a refresher and eventually solved my problems.

The post Sprint Retrospective 6 appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

This sprint we made huge advancements towards accomplishing our goals for the semester.  Unfortunately, due to the time constraints, we will not be able to produce a final product.  Hopefully, we will be able to provide something that the next class can build on and learn from what we are able to put together and pass on to them.

For this sprint, we each chose a different aspect of what was needed and each worked on different services that we planned to bring together at the end and the beginning of this next sprint before working on the presentation.  We ran into a lot of issues though during this sprint with having crypto-js importing correctly. I am unsure at this time whether the crypto-js library will be able to be used moving forward or if the team that works on encryption next semester will have to find a different library to use.  I do feel that we have learned a lot of lessons though. We were able to participate in a project the same way that we will when we start working after graduation. I believe that is more or less left to figure it out on our own and put into scrums will make the transition easier when we take on our first real-world project outside of school.  I believe that another part that worked against us is that none of us were quick enough or confident enough to step up into a leadership role to help guide the team and help make sure we were reaching goals throughout the sprint, as well as the other sprints.

This sprint I did learn a lot more about Angular and testing in Angular in particular.  The set up reminded me a lot of JUnit testing that we have done in the past. You start by declaring whatever variables are necessary at the beginning of the test.  If they are variables that you need to be repeated for multiple tests you can either put them under declare each or to declare once before any tests run. Then in your tests to state whether or not you expect to equal or not equal a specific outcome.  From there you will be presented with an output to let you know if the test either passed, failed, or failed to run successfully. I do hope that while we will not complete what we were asked to deliver, what we will present will help future classes and does not have to be thrown out completely.

The next sprint will be our final sprint and will also be a shortened sprint, roughly half the length as a regular sprint.  We will be preparing our final group presentations and it will be tough to do without having a set of deliverables to present to the rest of the class.  I do think that ours will be a little different than the rest of the groups as we will be focusing more the lessons that we learned from failing to meet the desired objective of this semester.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

This sprint felt much more productive than the previous sprints from my perspective.  I think that is mostly because we did more than research or creating test programs. This sprint we started writing services for the AMPATH project.  We created an encryption service, at this time it specifically focuses on hashing passwords. We also added a test for this method simultaneously, by the end of this sprint though we were unable to run the test successfully.  Moving forward that will have to be one of the focuses is to get this test working, I believe that it is necessary for us to get this test successful in order to use it as a template for creating our other tests. There are two pieces of wisdom that have stuck with me that I believe will really come in handy for this next sprint.  “Slow is smooth, smooth is fast” and “Those who fail to plan should plan to fail”.

If we rush into writing other tests without building a successful one I think that there is a very high chance that we will get in over our head with too many tests that will fail for various reasons and we will start to try and fix different issues at the same time and just creating more issues.  If we take our time and focus on fixing this test first then we will have a clear picture of what is needed to write successful tests. We need to slowly approach this to help the project from a larger perspective move smoothly and at a good pace.

Since we are quickly approaching the end of the semester and the end of the project, everyone participating in the next sprint planning meeting is crucial.  If we do not take the full opportunity to carefully plan out what we will each be doing over the next week and a half the risk of us falling incredibly far behind to not be able to produce any meaningful deliverable to the project and negatively affect the ability for the other teams to effectively move forward on their own projects.

The service we did write however is a good start, we created an encryption directory within src/app.  In this, we created a hashed password service that takes a string and hashes the string. In the spec service for the hashed password, we wrote a test to test if the hashed password does not equal the original string that was used as a test password.  The test originally failed and produced the error that “Cannot find type definition file for ‘source map’.” After doing some research I thought I found a solution for manually adding “@types/source-map” to the package.json folder. After adding this and running ‘npm install sourcemap@latest –save’ the new error that was given was that there were now conflicting definitions for source map.  The solution on stack overflow that I found called for doing both, but I will now try removing the line from the package.json folder and see if that produces any significant changes. Depending on what that produces will determine the direction that we move in from there.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

This sprint I learned a lot more about encryption services and typescript in general. Encryption using Javascript is not the best choice, especially in an open source project but I feel the solution we have will do the job and securely encrypt the data in the more secure way we can. I learned there are many solutions to our problem and a lot of solutions may be outdated or not maintained. We chose Crypto-JS to hash passwords and encrypt and decrypt data, it’s a popular Javascript crypto library and has an MIT license. The last update was a year ago but still feel this properly accomplishes what we want. I noticed there are a lot solutions for Javascript but not many are implemented in Typescript. I learned quite a bit about translating from Javascript to typescript and was able to implement a solution for an encryption function in a typescript service file. I learned more about testing in Angular 2 but still am having some trouble with tests. I will keep on focusing on writing good tests that comply with the Ampath standards. I enjoy getting to work on something that’s actually used by people, and will help people do their job. It’s nice to get experience working with a real web application that uses Javascript and APIs. I feel this will help me in my professional career, and will help the Ampath team improve their project.

I felt the team worked well during the sprint. We have all been having problems keeping the web application working and it seems to break even though the local files have not been touched. We all have the application working now and are on to writing the functions needed for the other teams to utilize. We have split up the tasks amongst ourselves and will hopefully have a working solution by the end of the the next sprint. I don’t see anything stopping up from completing the tasks, and we got the O.K. from Jonathan on the Ampath team on the encryption API interface. I am currently working on the encryptRecord function and am utilizing Crypto-JS for that. I have a function now that I think will do the job but still need to work on my angular 2 testing skills to make sure the function will work properly.

We began the sprint with the intention of creating an encryption service file that has the following functions: hashPassword, a function that hashes passwords with a salt when the user logs in. clearLocalSalt, a function that will clear the local salt generated at login, when the user logs out. encryptRecord, a function that takes data and a private key and encrypts the data for save local storage. decryptRecord, a function that takes the private key and encrypted data and decrypts it for when the user is connected to the internet. Now that we have a clear path and the O.K. from the ampath team, we can concentrate on our individual tasks and work the offline login team for assistance in generating a salt with a username and timestamp.

The post Sprint Retrospective 5 appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

During Sprint 4, our team worked individually on different encryption libraries to gain a little more insight into the quality and usability of each one. I continued to research WebCrypto API and found the performance of the library to be much faster than other encryption libraries.

The test platform was a MacBook Pro (MacBookPro11,5) with a 2.8 GHz Intel Core i7 running MacOS 10.13 Beta (17A306f) and Safari Technology Preview 35.

On the WebKit blog, authors noted what they thought the disparity was caused by, “Working with our JavaScriptCore team, we learned that the causes of these pure JavaScript implementations not performing well is that most of them are not actively maintained. Few of them take full advantage of our fast JavaScriptCore engine or modern JavaScript coding practices. Otherwise, the gaps may not be that huge.”  WebCrypto API also boasts better security models and gives an example why: “When developing with pure JavaScript crypto libraries, secret or private keys are often stored in the global JavaScript execution context.” Noting this leaves users extremely vulnerable as “keys are exposed to any Javascript resource being loaded”, and allows XSS attackers to steal the keys. WebCrypto API protects the secret or private keys by storing them completely outside of the Javascript execution context. Implementations on MacOS and iOS are based on CommonCrypto routines “which are highly tuned for our hardware platforms, and are regularly audited and reviewed for security and correctness.” They go on to say WebCrypto API is the best way to ensure the highest security protection. WebCrypto sounds like a great resource for quality encryption services but there are others that perform the same tasks and can do what we want securely. The team has decided to focus on CryptoJS, which in this case I don’t think performance will be a big issue, but will keep this information close because I may need it in the future.

I feel the team worked well during this sprint and learned a good amount amount each library. Respectively we worked on bcryptjs, webcrypto api, pouch-db/crypto-pouch, and forge. All options seemed to get the job done but felt that CryptoJS suited our needs the best, while still keeping in mind the Ampath team might have a different preferred encryption library. We all learned more about encryption, Javascript, and the use of Typescript services. My personal interest in security and encryption has increased after working on this project, and all the news we see every day about the privacy of consumers data being compromised.

The first week of the sprint, I spent researching WebCrypto API, looking for a solution to implement that into ng2-amrs. I found documentation but not many examples of how to implement it in Angular 2. I found examples written in Javascript but had trouble getting things to work. I found it difficult to  translate Javascript into Typescript, and how that is going to used in a Typescript service. While meeting with the team we decided that while the encryption libraries we all tested has their own pros and cons, we decided that CryptoJS best suits what we need to get an encryption service running. CryptoJS has more a little more information on how to implement what we need to get our encryption service running.

 

 

The post Sprint Retrospective 4 appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

This sprint was a little different than the others because the week of spring break was in the middle of our sprint.  I think for most of the team, and certainly know that this applies to myself, that the week of spring break threw off my rhythm of work.  I had plans for things to accomplish, but other things kept coming up to include taking a break from all school work and reset. Although we were able to accomplish several of our goals and move forward as a team.  We worked on different basic programs that used encryption in order to try and find which library would work best for this project. In the end, we chose the crypto-js library. Crypto-js is flexible enough that it can effectively encrypt a string to allow us to accomplish our goal of encrypting passwords.  It will also allow us to encrypt objects so that will make it easier to encrypt information inputted by the users. From what we can tell so far this will cover all of the encryption needs that were laid out in the user stories at the beginning of the semester.

We also talked and realized that we may not be moving at the best pace and are not where we are all happy to be for the project at this point in the semester.  It’s important that we realize that we can’t go back and change what has happened earlier in the semester. All we can do is realize what we may have done wrong and fix those issues moving forward to the rest of the semester.  We discussed it a little during our retrospective and will talk about it more when we plan our next sprint. We will keep the lessons that we learned both good and bad while moving forward and accomplishing as much as we can for the end of the semester.

As a positive, we realized a good formula for our team in regards to breaking up the larger tasks into smaller more manageable individualistic tasks for team members to accomplish.  I feel that we have developed a good level of communication throughout our team. In my opinion, I believe that it took us a little longer than we all would have liked to get to this level of comfort and ease of sharing ideas that we may be a little nervous of that is not one hundred percent correct and the best solution.  We have developed a more open communication and I have noticed that we are starting to share more ideas and that will help us for the next couple of sprints to effectively produce a product that can help the Ampath project improve.

One obstacle that we need to realize that we need to get over is that while we may have to write a basic encryption service we will also have to develop more communication will all of the other teams and work together to write the code that will go into each of their services that the other teams are developing.  If we don’t do this then all of the teams run the risk of the services not syncing up on the encryption level or the teams trying to use different encryption libraries because we did not proactively work with the rest of the class to prevent that issue from occurring.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

During sprint 3, I worked more with encryption services and Webstorm trying to create a working an Angular app that encrypts and decrypts data using Webcrypto API. I have been researching the Webcrypto API for some time as it is completely new to me, including Javascript. I learned that there are not many Angular related examples of the Webcrypto API but I did find an example using Crypto JS that I am also interested in and I believe it will help me understand cryptography and how its implemented in Angular.  This resource had a lot of good information including why Webcrypto API is a good choice.

• WebCrypto offers protection against overwriting (in Chrome), since window.crypto.subtle is read-only. This is good news for security but bad news for usability, because it makes it harder to work with polyfills.
• Non-extractable keys make it very hard for attackers to steal your keys. Therefore, the “JavaScript is always insecure” issue is mostly resolved. You can create a key, store it at the client, and use it. But if you don’t specify it, you can never read the key, which means that attackers cannot do so. Tip: Use IndexedDB to store the keys.
• WebCrypto uses SSL only (with the exception of localhost and extensions) which ensures that the data sent between the web server and the browser is encrypted and secure.

I think the team worked well on the day we were together in class. We missed class because of the weather and that was unfortunate because I feel more accomplished when I get to work with my team face to face. I am working hard learning about encryption, how it works, and what the current standard for secure web encryption is so we have a good path to start after getting the o.k. from the AMPATH team on a direction to go. I believe we are all learning something new about web cryptography, as we are all focusing on different javascript libraries. I plan to bring what I learn from the Webcrypto API to the team and allow us to make an informed decision on what encryption library we should choose.

During spring 3, I spend most of my time researching Web Cryptography API, including webcrypto-examples on GitHub. I’ve been using what I learn from the documentation and examples to get a working implementation on an app of my own to help the team move forward in creation of an offline module. I started focusing on the Webcrypto API because it seemed like a good starting point as it’s a popular javascript library that outperforms others significantly. The algorithm I am focusing on is AES-GCM, “the symmetric block cipher ratified as a standard by National Institute of Standards and Technology of the United States (NIST)” During the latest sprint meeting the team, we decided to keep working on our respective projects implementing an encryption service, once we meet after spring break we will began to make a game plan as to what to pitch to the AMPATH team.

The post Sprint Retrospective 3 appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

I feel that this sprint was good from the aspect that during the planning phase we seemed to come together more, and everyone added more input into tasks to break the items on the product backlog into and which ones we felt that we could accomplish during this sprint.  I feel that we are starting to hit our stride and be more comfortable as a team voicing opinions and ideas to each other.  Even though we are approaching the halfway mark in the semester without making too many contributions to the project.  From this last sprint into this upcoming sprint, each member of the team is making a bare-bones application with each one using a different encryption method.  When we meet again we will all have a better understanding of how encryption is applied in Angular and we can effectively suggest an encryption method to the Ampath team.   After that, I feel like we will have better direction and a better sense of purpose as a team since we will be working on services that can be applied to the project and feel more like we are contributing.

While our communication improved during the work classes we still have a lot of work to do communicating outside of class.  Some of our work classes were canceled due to snow and I believe that negatively impacted our team more than it should have.  Someone mentioned during the sprint review that the sprint would have gone better if we had been able to have more work classes.  While I don’t disagree with that statement it did make me think; did we utilize our time and communication ability between classes as much as possible?  I cannot honestly say that we did or feel like we accomplished all that we could in the time allotted.

I was assigned to create an application using crypto-js.  My first step was to do research, this included three different areas to focus on.  The first was encryption in general to get more familiarity with it, the second was how encryption was implemented in Angular, and the third part was to research crypto-js and how it was specifically implemented.  I found several examples of how to insert the encryption code into a program as well as one to create an Angular app to encrypt a file.  I lost the link to the site and am on the hunt to find it again, I was lucky enough to have downloaded the sample code already.

I hope that after spring break we can accomplish more as a team during our sprints and feel that we will after hitting these setbacks and discussing our team shortcomings at the sprint retrospectives we will keep improving every time.  After this upcoming sprint, we will be able to choose an encryption method with reasons why to back it up when we present it to Ampath.  Then I truly believe that we will have a renewed sense of purpose that will give the team the drive we need to meet our project goals by the end of the semester.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.