Laserfiche WebLink
SOLICITATION # CH16012 <br />MAA <br />CA MAA provides user management self-service to customers to manage their own <br />accounts and create accounts for other users. <br />CAAgile <br />The customer is responsible for managing the lifec cle of all user accounts. <br />ASM <br />The Purchasing Entity can manage their account and create sub -accounts within <br />ASM. <br />Google <br />Comply <br />AODocs <br />Comply <br />Virtru <br />Virtru does not have an identity system. We federate authentication to Oauth and Email loop <br />verification. <br />Salesforce <br />Identity Management <br />Logon is form -based. When users log into the Salesforce application, they submit a username and <br />password, which are sent to Salesforce via an TLS-encrypted session. Security features are <br />developed by Salesforce and built into the application. Third -party packages are not used for <br />development or implementation of security internal to the application. <br />In addition, single sign -on and two -factor authentication may be used to authenticate users. Some <br />organizations prefer to use an existing single sign -on capability to simplify and standardize their <br />user authentication. You have two options to implement single sign -on —federated authentication <br />using Security Assertion Markup Language (SAML) or delegated authentication. <br />Federated authentication using Security Assertion Markup Language (SAML) allows you to send <br />authentication and authorization data between affiliated but unrelated Web services. This enables <br />you to sign -on to Salesforce from a client application. Federated authentication using SAML is <br />enabled by default for your organization. <br />Delegated authentication single sign -on enables you to integrate Salesforce with an authentication <br />method that you choose. This enables you to integrate authentication with your LDAP (Lightweight <br />Directory Access Protocol) server, or perform single sign -on by authenticating using a token <br />instead of a password. You manage delegated authentication at the profile level, allowing some <br />users to use delegated authentication, while other users continue to use their Salesforce-managed <br />password. Delegated authentication is set by profile, not organization wide. You must request that <br />this feature be enabled by Salesforce. <br />Salesforce can be configured to utilize Active Directory directly via Delegated Authentication, or <br />indirectly via Federated Identity using either SAML 1.1, or SAML 2.0. Additionally your users can <br />be loaded from information drawn from your Active Directory servers and modifications made in <br />Active Directory can be propagated into Salesforce. <br />Customers can use their own SAML Identity Provider, or license one directly from Salesforce with <br />our Identity Connect product. <br />User Accounts <br />All users and application -level security are defined and maintained by the organization <br />administrator, and not by Salesforce. The organization administrator is appointed by the customer. <br />An organization's sharing model sets the default access that users have to each other's data. <br />There are four sharing models: Private, Public Read Only, Public Read/Write, and Public <br />Read/Write/Transfer. There are also several sharing model elements: Profiles, Roles, Hierarchy, <br />Record Ty es, Page Layouts, and Field Level security. <br />ServiceNow <br />Customers manage their own instances, including assigning users, defining user roles and <br />profiles, and administrating the system. ServiceNow does not have access to the Customer's <br />instances. The ServiceNow wiki has all ServiceNow documentation available. <br />carahsoft 165 carahsoft <br />