立即与支持人员聊天
与支持团队交流

Defender 6.6 - Administration Guide

Getting started Managing Defender objects in Active Directory Configuring security tokens Securing VPN access Securing Web sites Securing Windows-based computers Defender Management Portal (Web interface) Securing PAM-enabled services Delegating Defender roles, tasks, and functions Automating administrative tasks Administrative templates Integration with Active Roles Push Notifications Appendices
Appendix A: Enabling diagnostic logging Appendix B: Troubleshooting common authentication issues Appendix C: Troubleshooting DIGIPASS token issues Appendix D: Defender classes and attributes in Active Directory Appendix E: Defender Event Log messages Appendix F: Defender Client SDK Appendix G: Defender Web Service API

Push Notifications

A notification is a message that displays outside the contextual UI to provide the user with critical reminders or other information from a particular app on the mobile devices. Users can tap the notifications to open the app or take a predefined action directly from the notification. Push notifications for in-house and external (OneLogin) applications allow users in your organization to receive important notification messages on their compatible mobile devices.

NOTE: In case of both PUSH types token are assigned to the user, OneLogin token will get the precedence to receive the notification.

How the Defender Push Notification Works

The pushnotification feature is supported and configurable on both Android (version 8 or later) and iOS (iOS 10 or later) devices. The following sections describe the key Admin and User actions for using push notifications.

NOTE:Push notifications will not be triggered during authentication in offline mode.

Admin

User actions

  • From Defender 6.2 onwards, the pushnotification is implicitly triggered when user initiates the login authentication process to Defender eliminating the need to enter keyword PUSH in token field in first login attempt. The existing functionality with type in keyword PUSH works if the first login attempts fails to authenticate or times out.

  • The notification seeks a user response in form of Approve or Deny for access to the resources. Based on the user's response, the respective action takes place and the notification cycle completes.

  • In case of a timeout, the user can also use can use "push" keyword/passcode/Gridsure PIP.

  • Users activate the newly created token from the 6.1.0 release.

User friendly UX

DDL Client Authentication Process (Applicable from Defender 6.2) 

  1. When user initiates the Login process, the page asks for credentials only (username and password) and no passcode.

  2. The DSS automatically identifies if the user has a Defender Soft Token/OneLogin token configured on Android/iOS. In such case, the application sends a push notification to Defender Soft Token App/OneLogin Protect App. In presence of both tokens, priority will be given to OneLogin Push Notifications.

  3. If the user approves the push notification on Defender Soft Token App/OneLogin Protect app, they are prompted to next authentication login process to complete the cycle.

  4. If the user denies the push notification any time during the authentication process on OneLogin Protect app/Defender Soft Token App, the current login process gets canceled, and the user is redirected to the first Page to re-initiate the Login Process.

  5. If the user neither approves nor deny the push notification on OneLogin Protect app/Defender Soft Token App, then the notification times out for that request and user will be able to select one of the two options (if Authentication method is only Token of any policy) to continue with the authentication process as below:

    1. User can trigger the push notification again by clicking on SUBMIT button.

    2. Or user can enter "push" (without quotes, case insensitive) passcode/keyword in passcode field or use Gridsure PIP for authentication.

  6. When DSS identifies that a user does not have Android or iOS token configured, application will prompt the next authentication action (according to the token and Policy selected) on screen for user to complete the login process.

  7. If User has selected “Remember password option” under GINA settings, login screen will be prompted with pre-filled password in read only with enabled Submit button to continue the authentication process. Applicable only on the second login attempt, after denial/timeout of first login request.

EAP Client Authentication Process (Applicable from Defender 6.2) 

  1. When user initiates the Login process, the page asks for credentials only (username and password) under Networks in EAP client.

  2. The DSS automatically identifies if the user has a Defender Soft Token/OneLogin Token on Android or iOS configured and sends a PUSH notification to OneLogin Protect app/Defender Soft Token App while displaying a message confirming the notification sent process.

  3. If the user approves the push notification on OneLogin Protect app/Defender Soft Token App, they are prompted to next authentication login process to complete the cycle.

  4. If the user denies the push notification any time during the authentication process on OneLogin Protect app/Defender Soft Token App, the current login process gets canceled, and user has to re-initiate the login process.

  5. If the user neither approves nor deny the push notification on OneLogin Protect app/Defender Soft Token App, then the notification times out for that request. The user can now select one of the two options (if Authentication method is only Token for any policy) to continue with the authentication process as below:

    1. User can trigger the push notification again by clicking the RESEND button.

    2. Or user can enter "push" (without quotes, case insensitive) passcode/keyword in passcode field.

  6. If DSS identifies that a user does NOT have Android or iOS Token, application will prompt the next authentication action (according to the token and Policy selected) on screen for user to complete the login proces

  7. In case no response is received from the user on the Defender Soft Token App then the request times out and user can select between two options to continue the authentication process as below:

    1. User can trigger the push notification again by clicking on RESEND button.

    2. Or user can click the Sign in with another option button and enter "push" (without quotes, case insensitive) passcode/keyword in passcode field.

  8. GridSure Token is not supported with EAP Client.

ISAPI Client Authentication Process (Applicable from Defender 6.2) 

  1. When user initiates the login process, the page simply asks for ‘username’.

  2. If DSS detects dual Defender Soft Token/OneLogin Token on Android/iOS, application will send a Push Notification to OneLogin Protect app/ Defender Soft Token App.

  3. In the meantime, a waiting page is displayed on the ISAPI client with a message, "Defender needs to verify your identity. We sent a notification to your Defender Soft Token app. Please respond on your device to continue."

    NOTE:The waiting page also displays the ‘Sign in with another option’ button. The user can choose to sign in with token with out waiting for the push notification to be responded/timed-out.

  4. If the user approves the push notification on OneLogin Protect app/Defender Soft Token App, they are prompted to the next authentication login process to complete the cycle.

  5. If the user denies the push notification any time during the authentication process on OneLogin Protect app/Defender Soft Token App, the current login process gets canceled, and user is redirected to a page displaying a message regarding verification denial.

    NOTE:The Ok button on the verification denial page can be used to re-initiate the login process.

  6. In case no response is received from the user on the OneLogin Protect app/Defender Soft Token App then the request times out and user can select between two options to continue the authentication process as below:

    1. User can trigger the push notification again by clicking on RESEND button.

    2. Or user can click the Sign in with another option button and enter "push" (without quotes, case insensitive) passcode/keyword/Gridsure PIP in passcode field.

  7. If DSS identifies that a user does NOT have Android or iOS Token, application will prompt the next authentication action (according to the token and Policy selected) on screen for user to complete the login process.

Push notification timeout configurable

  • The Push Notification verification timeout is a configurable value.

  • On a computer where Defender Security Server is installed, use Registry Editor to create the following value at:

    HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\PassGo Technologies\Defender\DSS Active Directory Edition

    Value type: REG_DWORD

    Value name: NOTIFICATIONTIMEOUT

    Value data: XX

    NOTE:

    • The value can range between decimal 1 to 30. Any other value beyond this range is invalid and will set the default timeout to 30 seconds.

    • In case if the registry key for the timeout is not found (not added), then the default timeout of 30 seconds is set.

    • The server will wait till the timeout seconds before sending the response back to client.

Defender push notifications can be disabled

  • To turn the notifications off, the user needs to manually create the following registry value at:

      Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\PassGo Technologies\Defender\DSS Active Directory Edition

      Value type: REG_DWORD

      Value name: PushOff

      Value data: XX

  • The value can be either 0 or 1. Any other value beyond this range is invalid and will set the defaul t push notification on. In case if theregistry key for the PushOff is not found (not added), then the default push notification on is set.

Setup Instructions for Firebase Communication

Firebase deprecated legacy APIs to communicate with Firebase server. And informed all Apps using the deprecated FCM legacy APIs for HTTP and XMPP should migrate to the HTTP v1 API at the earliest opportunity. Updated to latest Firebase HTTP v1 API in v6.5.1, enhancing security measures to enable Push Notification functionality within the Defender Soft Token app.

Migrate from legacy FCM APIs to HTTP v1

In addition to ongoing support and new features, the HTTP v1 API has these advantages over the legacy APIs:

  • Better security via access tokens: The HTTP v1 API uses short-lived access tokens according to the OAuth2 security model. If an access token becomes public, it can only be maliciously used for an hour or so before it expires. Refresh tokens are not transmitted as often as the security keys used in the legacy API, so they are much less likely to be captured.
  • More efficient customization of messages across platforms for the message body: The HTTP v1 API has common keys that go to all targeted instances, plus platform-specific keys that let you customize the message across platforms. This allows you to create "overrides" that send slightly different payloads to different client platforms in a single message.
  • More extendable and future-proof for new client platform versions: The HTTP v1 API fully supports messaging options available on Apple platforms, Android and Web. Since each platform has its own defined block in the JSON payload, FCM can extend the API to new versions and new platforms as needed.

Points to consider in Customer Network for communication with Firebase

When upgrading to Firebase HTTP v1 API Then these are network-related details Customer need to verify so that their firewall or proxy settings allow smooth communication with Firebase servers. Here are the key points to share:

  1. Firebase HTTP v1 API Endpoints: Ensure the customer whitelists the necessary endpoints that the Firebase API uses. Commonly used endpoints include:

    • https://fcm.googleapis.com/fcm/send (for sending push notifications)
    • https://fcm.googleapis.com/ (general Firebase Cloud Messaging API)
    • https://fcm.googleapis.com/v1/projects/defender-302218/messages:send
    • https://identitytoolkit.googleapis.com
    • https://securetoken.googleapis.com
    • https://www.googleapis.com/auth/firebase.messaging
    • OAuth 2.0 Authentication (if using OAuth 2.0 for access tokens):
      • https://oauth2.googleapis.com

  2. Ports to Allow:

    • HTTPS Port 443: The Firebase API uses secure HTTPS connections over port 443. This port must be open for outbound traffic to communicate with Firebase servers.

  1. IP Address Range: Firebase does not provide a static set of IP addresses, as Google services operate on dynamic IPs that change over time. It’s recommended to whitelist the domain googleapis.com rather than specific IP addresses.

  2. SSL/TLS Certificates: Firebase uses SSL/TLS for secure communication. Ensure that their firewall/proxy supports SSL inspection or has the necessary root certificates to allow the secure connection. If the customer's environment uses SSL decryption or inspection, they may need to configure exceptions for Firebase URLs to avoid issues with SSL handshakes.

  3. Timeouts and Retries: Recommend configuring reasonable timeouts and retry policies for network requests in the application. This ensures that temporary network issues do not cause failures in delivering messages.

By configuring this information, customer's network configuration allows the application to communicate with Firebase effectively.

Appendices

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级