In its response, the IdP attaches this token, thereby indicating the validity of authentication requests. For login attempts, Druva sends a request to the IdP (typically using HTTP POST). The SSO token uniquely identifies Druva login requests.
#INSYNC PROVIDER LOGIN UPDATE#
To enable SSO access for users and administrators you must configure Druva to recognize IdP details that you obtained when you performed Task 1.Īfter you configure Druva for Single Sign-On, the Druva Cloud Platform Console provides an option to generate SSO Token. To allow your IdP to recognize requests that Druva sends, you must first generate an SSO token, and then update your IdP configuration with this token. If your organization is using an IdP, you must work with your IdP to get details such as IdP URL and IdP certificate.ĭruva supports leading IdPs such as Okta, PingIdentity, OneLogin, and Active Directory Federation Services (ADFS). Task Numberīefore you enable SSO, you must first set up a corporate database with an Identity Provider (IdP). This table describes the chronology that you should follow for enabling SSO for the administrator and user access. Note: Contact Support for assistance to configure a IdP that is not listed under Certified IdPs.
#INSYNC PROVIDER LOGIN WINDOWS#
Windows Server 2008 R2 (64-bit) is certified to work with ADFS 2.0.Windows Server 2012 R2 (64-bit) is certified to work with ADFS 3.0.Active Directory Federation Services (ADFS).Issues that require time and resources beyond commercial viability may not be addressed. Druva will provide support for such IdPs. Supported IdPs - A supported IdP is not tested by the Druva QA team with every cloud release, however, the SSO functionality should work as expected.Druva certifies these IdPs and performs regular testing with every cloud release to ensure the SSO functionality works as expected. Certified IdPs - A certified IdP is fully tested by Druva Quality Assurance (QA) team.This section provides information on the SAML IdPs that Druva certifies and supports.ĭruva categorizes its IdP support levels as follows: Upon receiving this response, Druva denies access to Druva Cloud Platform Console.ĭruva integrates with the majority of the SAML IdPs. However, if the IdP does not find a match within its database, it sets assertion in HTTP POST to False, thus indicating that the administrator is not authorized to access Druva Cloud Platform Console. Druva receives the assertion, which indicates that the administrator is validated, and allowed access to Druva Cloud Platform Console. The IdP validates the SAML query, sets assertion in HTTP POST to True, and sends this response to Druva. For every login attempt, Druva sends SAML requests to the IdP login URL specified under > Druva Cloud Settings > Access Settings > Single Sign-On > Edit. However, if you use a preconfigured IdP or if this is a subsequent login, Druva uses SAML assertions in an HTTP POST profile to communicate with your IdP. The administrators can now access the Druva Cloud Platform Console without individual passwords. The IdP redirects the user to the Druva Cloud Platform Console. If you created a corporate database with an IdP for the first time, administrators logging on for the first time are redirected to an IdP login details page that prompts the user for a one-time provision of passwords. The IdP maintains a record of all usernames and their subsequent passwords in an encrypted format.
If you already have an IdP, you can configure Druva to work with this IdP. To enable SSO, an administrator must first work with an Identity Provider (IdP) to create a corporate database that includes all Druva administrators. Federated authentication allows Druva to skip the validation of passwords. Druva supports SSO by implementing federated authentication using Security Assertion Markup Language (SAML) version 2.0.
0 kommentar(er)
