Protected Systems are applications, services, or infrastructure that you want to protect with SGNL. In this guide, we’ll describe how to achieve fine-grained access control at sign-in time with Okta and SGNL, enabling the right amount of access to applications and infrastructure connected to Okta. If you’d like to learn more about whether fine-grained Sign-In Policies with Okta and SGNL is right for your enterprise, visit our Securing AWS Blog or watch the video below to learn more.
With this integration, Okta need not know about the policies, systems of record, or any of the data in SGNL - it simply needs to pass to SGNL:
Authentication ensures that only authorized systems can make requests into SGNL, as well as verifying the identity of an integration in order to effectively evaluate Policies - to access Authentication settings, open your AWS protected system and select the Authentication tab
Click Generate Token
Give your token a descriptive name so that you know how it’s being used in the future and click to Generate Token
On the next screen, copy the token - this will be used by Okta to make access requests to SGNL using the SGNL Access Service API
Note: The value of this token is not available again after this screen, so ensure you securely store it for steps later in this guide
Integrating SGNL with Okta, for the purposes of securing AWS or any Application, relies on Okta Inline Hooks. Okta Inline Hooks enable Okta to make an outbound request that can be routed to SGNL, in order to determine whether a user should have access to a specific application at that point in time, or what roles, claims, or tags to include in their SAML assertion
A simple example of this in action is using Okta Hooks to ask whether a user can access a specific customer’s data in AWS for a given session. In this scenario, SGNL Customers have found that PrincipalTags offer the greatest level of flexibility and dyamism, when combined with existing AWS roles, to dynamically specify an individual principal’s (user, service, robot, etc) permissions for a given session.
AWS provides the flexibility to enable Principal Tags to be used directly in conjunction with other policies that might already exist in AWS, and enables interleaving the tag directly into a resource name.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::sensitive-prod-${aws:PrincipalTag/customerId}*"
},
...
]
}
To get the appropriate set of access for a given session (and consequently the necessary tag), an inline hook is routed to SGNL at authentication time. The hook specifies the Customer ID for which the user is requesting access.
SGNL’s Access Service responds with a determination whether the acess to a specific customer is allowed for a given session:
{
"decisions": [
{
"action": "access",
"assetId": "{{customerId}}",
"decision": "Allow"
}
],
"evaluationDuration": 8,
"issuedAt": "2023-06-22T23:49:32.087875656Z",
"principalId": "alice.wu@sgnl.ai"
}
If Access is Allowed, the Customer’s ID is packaged into the Okta SAML Assertion as a PrincipalTag and then the user is redirected to AWS to be signed in. At policy evaluation time, AWS inspects the Principal Tag and appropriate policy, determining whether the principal should be allowed to access a given resource.
At this point, it’s likely that all decisions will either be Allow or Deny, based on the Default Decision you’ve selected for the Okta Integration - if that’s the case, you’re ready to start assigning policies.
Once the Okta integration is created, you can start assigning versions of Policies - to get started, select Policies from the tabs in your newly created integration
Select ‘Assign Policies’
Select:
Click Next once you have the Policies and Versions configured as is appropriate
Select the Enforcement mode for the Policies you chose in the previous step
Simulated: Policy Versions that are being simulated will only log their access decision in the SGNL logs and will not impact the access decision that SGNL hands back to an integration. Simulated policies are useful for performing what-if analysis of new policy versions as well as debugging policy changes.
Note: It’s considered best practice to start with policies in Simulated mode, to verify that policies have been created an applied as expected
Enforced: Policy Versions that are being enforced will impact the access decisions that SGNL hands back to an integration. Enforced Policies will determine access for an integration
Select your desired Enforcement mode and select Assign
Versions of Policies will now be Assigned to your integration
As part of the SGNL CAEP Hub, Okta can be configured to receive Okta User and Device Risk events from SGNL, as well as standards-based CAEP Events. Follow the steps below to configure Okta to enable this integration.
https://{{YourOktaOrg}}.okta.com/security/api/v1/security-events
Refer to Okta’s Documentation for configuring an Okta Shared Signals Framework Receiver. In order to complete the configuration, you will need:
https://console.sgnl.cloud/api/config/metadata/v1/.well-known/ssf-configuration
https://sgnl.ai
From within SGNL you can configure any change in the graph to trigger actions that are directed to downstream systems. In an example scenario, you may want to trigger an Okta User Session Risk event when an end-user’s Azure AD Risk level is High. To complete this example integration, we assume someone has already configured Azure AD/Entra ID as a System of Record in SGNL:
riskLevel
is equal to “High”${.OktaUser.profile__email}
That’s it. Once you’ve finished configuring your rule, the next time a User’s device is out of compliance, SGNL will send Okta a Session Revoked event and report that as risky.