From 7dd84f37f0575f721f7c59d89a034e03d511d352 Mon Sep 17 00:00:00 2001
From: Himanshu Mishra <himanshu@orkohunter.net>
Date: Thu, 20 May 2021 11:53:47 +0200
Subject: [PATCH] Apply suggestions from code review
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Himanshu Mishra <himanshu@orkohunter.net>

Co-authored-by: Fredrik Adelöw <freben@gmail.com>
Co-authored-by: Patrik Oldsberg <poldsberg@gmail.com>
---
 docs/auth/identity-resolver.md                  | 16 ++++++++--------
 plugins/auth-backend/src/lib/catalog/helpers.ts |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/auth/identity-resolver.md b/docs/auth/identity-resolver.md
index f1f99bde71..fa344afcef 100644
--- a/docs/auth/identity-resolver.md
+++ b/docs/auth/identity-resolver.md
@@ -12,7 +12,7 @@ Backstage entity by a user. The ideas here were originally proposed in the RFC
 [#4089](https://github.com/backstage/backstage/issues/4089).
 
 When a user signs in to Backstage, inside the `claims` field of their Backstage
-ID Token (which are standard JWT tokens) a special `ent` field is set. `ent`
+Token (which are standard JWT tokens) a special `ent` claim is set. `ent`
 contains a list of
 [entity references](../features/software-catalog/references.md), each of which
 denotes an identity or a membership that is relevant to the user. There is no
@@ -41,7 +41,7 @@ export default async function createPlugin({
             }
 
             // Ignore email addresses which do not belong to company's domain name
-            if (email.split('@')[1] != 'mycompany.com') {
+            if (email.split('@')[1] !== 'mycompany.com') {
               throw new Error('Unrecognized domain name of the email ID used to sign in.')
             }
 
@@ -82,11 +82,11 @@ export default async function createPlugin({
 }
 ```
 
-As you can see, the generated Backstage ID Token now contains all the claims
-about the identity and membership of the user. Once the sign-in process is
-complete, and we need to find out if a user owns an Entity in the Software
-Catalog, these `ent` claims can be used to determine the ownership. A full
-algorithm as proposed in the RFC is as follows
+As you can see, the generated Backstage Token now contains all the claims about
+the identity and membership of the user. Once the sign-in process is complete,
+and we need to find out if a user owns an Entity in the Software Catalog, these
+`ent` claims can be used to determine the ownership. A full algorithm as
+proposed in the RFC is as follows
 
 The definition of the ownership of an entity E, for a user U, is as follows:
 
@@ -126,7 +126,7 @@ export default async function createPlugin({
 
 ## Profile transform
 
-Similar to a custom sign-in resolver, you can also write custom profile
+Similar to a custom sign-in resolver, you can also write a custom profile
 transformation function which is used to verify and convert the auth response
 into the profile that will be presented to the user. This is where you can
 customize things like display name and profile picture.
diff --git a/plugins/auth-backend/src/lib/catalog/helpers.ts b/plugins/auth-backend/src/lib/catalog/helpers.ts
index e155c7defe..c60198dc98 100644
--- a/plugins/auth-backend/src/lib/catalog/helpers.ts
+++ b/plugins/auth-backend/src/lib/catalog/helpers.ts
@@ -29,7 +29,7 @@ export function getEntityClaims(entity: UserEntity): TokenParams['claims'] {
       ?.filter(
         r =>
           r.type === RELATION_MEMBER_OF &&
-          r.target.kind.toLocaleLowerCase() === 'group',
+          r.target.kind.toLocaleLowerCase('en-US') === 'group',
       )
       .map(r => stringifyEntityRef(r.target)) ?? [];