PSC Tech Talk: Using Chrome Profiles for Office365 developers

In this presentation one of our Directors @MarkyRoden gave a short presentation on using Chrome profiles to help manage your life as a developer.

Mark gave the example of having a chrome profile for each of his customers and how he takes advantages of the features the profiles provide.

Using Chrome profiles you can:

  • Store separate bookmarks per profile
    • This means that you can create specific bookmarks just for that customer and/ or that development environment.
  • Different homepages
    • You can create a unique set of pages which always opens for each individual profile. For his salesforce instance Mark has the SalesForce tenant open automatically, for his Azure dev profile, Mark has portal.azure.com open automatically.
  • It remembers you
    • When you log into a website like Office365 for example, you can allow the system to remember who you are and now ask you for authentication every time. These credentials are remembered separately for each profile. Using this Mark can log into him development instance of Office365 by opening the profile and when he opens his PSC instance of Office365 in his Work profile, he is logged into the PSC Office 365 tenant.
  • Chrome extensions
    • Each profile has it’s own set of chrome extensions. So those which are useful for salesforce development, are only available in the salesforce profile.
  • Microsoft Teams
    • Right now you cannot log into two separate client instances within one Teams Client instance. Mark uses his client profiles so that he can access teams for each organization separately within their own tenant, while keeping them all separate from each other.

 

 

 

Advertisements

PSC Tech Talks – Securing AWS Lambdas

During this PSC Tech Talk, Roger Tucker gave an in depth technical talk on how to create signatures and the secure HTTP headers necessary to have secure authenticated access to calling and executing Amazon Web Services (AWS) Lambdas.

What are AWS Lambdas?

AWA Lambdas are a serverless service that runs your code in response to events and automatically manages the underlying compute resources.

PSC uses Lambdas for a number of AWS projects which we create and manage for our clients. The advantages of Lambdas are that they self-scale, and the client is only billed for the time the lambads are running. The presentation was not about the right way (there are many) to architect a Lambda based application. That would be for another day.

Samples Lambdas

Roger showed how to create a simple Lambda function in and call it via an unsecured API Gateway endpoint. Using the Postman tool he demonstrated how the response can be triggered from an unsecured API Gateway endpoint in a development environment.

Roger set a different API Gateway endpoint to use IAM (Identify access manager) security. He allowed the TestLambda user to have access to one resource – the secure demo api.

 

His initial attempt to call the enpoint using Postman with no Authorization provided resulted in a “missing authentication token” message.

In the next attempt the AWS signature option was selected in postman.  He provided the appropriate AWS credentials, region and service name in Postman and resubmitted the request.  We saw how Postman allows us to create the AWS Signature and HTTP header for the sake of testing. And now that the test user has access, we can see the proper response from the endpoint.

 

Creating the signature

Roger demonstrated how to create the Signature necessary for the HTTP header. Starting with a Canonical Request, your AWS credentials, endpoint region, and service you can create the signature. The signature is then used to create the HTTP header.

The hashed response to the canonical request “e3boc……”then becomes an input for a string which is needed to generate the signature.

Using the string to sign (containing the credential scope) we then create the Signature and this is what is attached to the api call as an Authorization header.

There are multiple levels of hashing, this is intentionally complicated, so as to make the Lambdas as secure as possible. This signature must make the necessary hash generated on the server to allow the authorization to be allowed.

Roger then closed out the presentation by showing how his Python code creates these separate credentials and how he can then call the secure Lambda directly.

Conclusion

Securing Lambdas is a complex process, this is by design to ensure that an open endpoint cannot be called by a rogue service.