Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AppIntegrity Feature #232

Merged
merged 1 commit into from
Oct 25, 2023
Merged

AppIntegrity Feature #232

merged 1 commit into from
Oct 25, 2023

Conversation

jeyanthanperiyasamy
Copy link
Contributor

JIRA Ticket

Please, link jira ticket here.

Description

Briefly describe the change and any information that would help speedup the review and testing process.

Definition of Done Checklist:

  • Acceptance criteria is met.
  • All tasks listed in the user story have been completed.
  • Coded to standards.
  • Ensure backward compatibility.
  • API reference docs is updated.
  • Unit tests are written.
  • Integration tests are written.
  • e2e tests are written.
  • Functional spec is written/updated.
  • Example code snippets have been added.
  • Change log updated.
  • Documentation story is created and tracked.
  • Tech debts and remaining tasks are tracked in separated ticket(s).

@@ -57,6 +57,11 @@
BlueprintName = "FRAuthTests"
ReferencedContainer = "container:FRAuth.xcodeproj">
</BuildableReference>
<SkippedTests>
<Test
Identifier = "AA_07_AppIntegrityTest/test_01_test_app_integrity()">

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we skipping this? Should that be committed

Copy link
Contributor Author

@jeyanthanperiyasamy jeyanthanperiyasamy Sep 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests are written and the classes are committed, i just disabled tests because it will only work in local box for now and feature is not available in AM , so when the AM is ready we will add this test back. otherwise it will fail the tests in bitbar when this story merge to dev branch

case .featureUnsupported:
return "Unsupported"
default:
return "ClientDeviceErrors"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest we centralize the strings for errors or outcomes. Either in a utility class (we might have one already) or at least top of the file, on a let

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

taken care , i abstracted all the errors in to his own enum.

}
self.assertToken = assertKey

guard let clientData = inputNames.filter({ $0.contains("IDToken1clientData") }).first else {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make the keys lets or a an enum

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addressed


/// Protocol to override attestation
@available(iOS 14.0, *)
public protocol FRAppAttestation {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we consider FRAppAttestation , FRAppAttestDomainModal, FRAppAttestService as internal class?
Do we need developer to have access of those interfaces?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@witrisna i think the constructor injection in once of class made all the cascading class to public, i have provided the fix, this will be internal . if you remove public its default to internal in swift . Good Catch

Copy link
Contributor

@rodrigoareis rodrigoareis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall changes looks good. Minor comments added on top what was already spotted.

/// - keyIdentifier: The identifier you received when generating a cryptographic key by calling the generateKey(completionHandler:) method.
/// - clientDataHash: A SHA256 hash of a unique, single-use data block that represents the client data to be signed with the attested private key.
/// - Returns: A data structure that you send to your server for processing OR A DCError instance that indicates the reason for failure, or nil on success.
public func generateAssertion(keyIdentifier: String, clientDataHash: Data) async throws -> Data {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add Throws to doc

}

/// Creates a new cryptographic key for use with the App Attest service.
public func generateKey() async throws -> String {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add Throws and Returns to doc

}

/// A Boolean value that indicates whether a particular device provides the App Attest service.
public func isSupported() -> Bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add Returns to doc

Copy link
Contributor

@vahancouver vahancouver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments to address

Overall looks great. Great amount of test coverage

///
/// - Parameter service: FRAppAttestService to connect AppAttestation server
/// - Parameter bundleIdentifier: BundleId of the application
/// - encoder encoder: Encoder to endode the Data
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should read "- Parameter encoder" and there is a type in encode word

/// Handle attestation and assertion
/// - Parameter challenge: Challenge Received from server
/// - Returns: FRAppIntegrityKeys for attestation and assertion
public func attest(challenge: String) async throws -> FRAppIntegrityKeys {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add throws to docs

default:
return FRAppIntegrityClientError.clientDeviceErrors.rawValue
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of this map Error method, I suggest adding a property in FRDeviceCheckAPIFailure like this code below. I think it's cleaner especially when using it

var clientError: String {
switch self {
case .featureUnsupported:
return FRAppIntegrityClientError.unSupported.rawValue
default:
return FRAppIntegrityClientError.clientDeviceErrors.rawValue
}
}

Copy link
Contributor Author

@jeyanthanperiyasamy jeyanthanperiyasamy Sep 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perfect, i like this one. lets do this @vahancouver

@available(iOS 14.0, *)
public protocol FRAppAttestation {
func attest(challenge: String) async throws -> FRAppIntegrityKeys
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add doumentation for protocol methods as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am about to modify this and make as a internal protocol . i am happy to add it if thats a team standard, but i like to add docs for any public facing methods

func attest(keyIdentifier: String, clientDataHash: Data) async throws -> Data
func generateAssertion(keyIdentifier: String, clientDataHash: Data) async throws -> Data
func isSupported() -> Bool
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add doumentation for protocol methods as well?

public private(set) var assertToken: String

/// keys received from AM
private enum keys: String {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Enum name should be uppercase

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i will remove this keys enum and add in to the CBConstants

case clientError = "IDToken1clientError"
case keyId = "IDToken1keyId"
case clientData = "IDToken1clientData"
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also in other callbacks we never add local Keys enum. we try to reuse CBConstants, and if anything is missing, let's add there

/// - Parameter attestation: Optional Protocol for providing a ``FRAppAttestation`` to implement own attestation
@available(iOS 14.0, *)
public func attest(attestation: FRAppAttestation
= FRAppAttestDomainModal()) async throws {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add throws to docs

@jeyanthanperiyasamy
Copy link
Contributor Author

jeyanthanperiyasamy commented Oct 2, 2023

all the comments where addressed , please review one more time and we can call this complete @vahancouver @george-bafaloukas-forgerock @rodrigoareis @witrisna .

Copy link
Contributor

@vahancouver vahancouver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good. All comments addressed

@jeyanthanperiyasamy jeyanthanperiyasamy merged commit 17f4e99 into develop Oct 25, 2023
5 of 7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants