TIB 2.0 Administration Functions Overview
Table of Contents 1. INTRODUCTION 4 1.1. Purpose/Background 4 1.2. Definitions, Acronyms and Abbreviations 4 2. OVERVIEW 5 2.1. Overall Process Map 5 3. ADMINISTRATOR FEATURES 6 3.1. Organization Invitation and Registration 6 3.1.1. Description 6 3.1.2. Process Map 7 3.1.3. Example Screenshot 7 3.2. Organization Management 13 3.2.1. Description 13 3.2.2. Process Map 14 3.2.3. Example Screenshots 15 3.3. Community Creation 19 3.3.1. Description 19 3.3.2. Process Map 20 3.3.3. Example Screenshots 20 3.4. Identity Provider Registration and Management 20 3.4.1. Description 20 3.4.2. Process Map 21 3.4.3. Example Screenshots 21 3.5. Service Provider Registration and Management 28 3.5.1. Description 28 3.5.2. Process Map 28 3.5.3. Example Screenshots 28 3.6. Export MetaData 31 3.6.1. Description 31 3.6.2. Example Screenshot 31 3.7. Manage Provider Status 34 3.7.1. Description 34 3.7.2. Example Screenshots 34 3.8. Manage Certificates 35 3.8.1. Description 35 3.8.2. Example Screenshot 35 3.9. Service / Application Registration 42 3.9.1. Description 42 3.9.2. Process Map 42 3.9.3. Example Screenshots 42 Page 2 of 55
3.10. Providers Join Community 43 3.10.1. Description 43 3.10.2. Process Map 44 3.10.3. Example Screenshots 45 3.11. Application Join Community 48 3.11.1. Description 48 3.11.2. Process Map 49 3.11.3. Example Screenshots 49 3.12. Setup Trust Relationship between Providers 52 3.12.1. Description 52 3.12.2. Process Map 52 3.12.3. Example Screenshots 52 Page 3 of 55
1. Introduction 1.1. Purpose/Background The purpose of this document is to describe the features of Covisint Trust Identity Broker (TIB) 2.0 Administration processes and functions. 1.2. Definitions, Acronyms and Abbreviations Term Authentication Authenticator Credential Federation Identity Identity Broker (IdB) Identity Management Realm (IdM Realm or Realm) Identity Provider (IdP) Principal Security Assertion Markup Language (SAML) Security Group Service Provider (SP) Role Security Token Service Service Package Definition The process used to verify a principal and bind the principal to their identity. A key that is used to verify a principal in an authentication process. Examples of authenticators include: passwords, two-factor software tokens (i.e. PKI certificates), two-factor hardware tokens (i.e. SecurID), biometrics, etc. A unique identifier (i.e. User ID) and the associated authenticator that is used to bind the principal to their identity in an authentication process. The ability to utilize identities from one security domain within another using a pre-established trust relationship between the participating entities. The IdP is responsible for making an identity assertion and the SP is responsible for providing the appropriate service(s) to the identity s principal. The digital representation of a principal described by its assigned characteristics; which are the credential, the attributes that describe the principal, and the permissions which have been granted to the principal. Provides support for protocol translation allowing an IdP and SP to use different federation protocols. Provides support for attribute mapping allowing an IdP and SP to use different attribute names to reference the same identity information. An IdB receives incoming assertions from IdPs using formats and protocols which are specific to each individual IdP and subsequently translates and routes the assertions for consumption by authorized SPs using the formats and protocols required by each individual SP. An IdM Realm defines the set of all users (and the services that are available to be granted to those users) based on a set of established federation trust relationships with participating IdPs and/or SPs. An entity that is responsible for the creation and management of a principal s identity, the authentication of the principal, and the federation of the principal s identity to an SP or a Federation Broker. An individual or system. An XML-based framework for securely communicating identity information (unique identifier, attributes, and permissions) between security domains through a federation. Defines the specific set of users that are managed by an administrator(s) as well as their available services. Security Group administrative relationships are defined by Security Group hierarchies. An entity that consumes an inbound federation from an IdP or a Federation Broker for the purpose of providing a service(s) to the identity s principal. Defines a business function that a permission or group of permissions can be assigned to. When a role is granted to a principal it gives the principal all the associated permissions. A generic term that may be applied to describe a Kerberos ticket, session cookie, assertion, etc. An application or site. A service is typically represented as a URL. A grouping of one or more services that must be requested and granted as a group. Service packages also contain additional information about the services (i.e. User must accept Terms & Conditions to gain access). Service packages, not services, are Page 4 of 55
Term SSO Definition requested and granted. Single Sign-On. A principal is able to do a single initial authentication within a local security domain making the principal s identity information available (via a security token) to the local security domain. And through federation, the principle s identity information can also be made available to any other federated security domains. 2. Overview TIB 2.0 Administration Functions are used to manage the cryptographic trust relationships with Covisint required to support identity federations. They allow IdPs and SPs to be invited and register with the Covisint TIB service, define the federation protocol that will be used by the Provider, and establish the specific assertion attribute map that will be utilized during a federation. They also provide features for certificate management between the Provider and the TIB required to maintain the trust relationship. 2.1. Overall Process Map Org A Registered in TIB and the Registrant accepted the Security Admin Role, who could Invite other Admins to Join the Org TIB Admin Creates a Community owned by an Org TIB Admin or Community Admin Send Org Registration Invitations Org B Registered in TIB and the Registrant accepted the Security Admin Role, who could Invite other Admins to Join the Org Provider Admin Creates a SP Application Configuration Admin Creates Application (SP) Provider Admin Requests (Provider and Application) to Join Community Org C Registered in TIB and the Registrant accepted the Security Admin Role, who could Invite other Admins to Join the Org Provider Admin Creates an IdP (IdP) Provider Admin Requests to Join Community Community Admin Approves Requests of Join Community (IdP) Provider Admin Requests Trust Relationship (with SP) (SP) Provider Admin Approves Request of Trust Relationship (from IdP) (SP) Provider Admin Requests Trust Relationship (with IdP) (IdP) Provider Admin Approves Request of Trust Relationship (from SP) Ready for Federation of IdP User to SP Application Figure 1 Overall Process Map of Setting up Trust Relationship Between SP and IdP Figure 1 shows the overall process flow of setting up trust relationship between SP and IdP. At high level, the process includes following key steps: Registration of Organizations with Covisint TIB (invited and approved by TIB Administrator or Community Administrator) o Organization that will be community owner o Organization that will own IdP(s) o Organization that will own SP(s) and application(s) Creation of Community Creation and Configuration of Providers Page 5 of 55
o Identity Provider o Service Provider Creation of Application(s) under SP Providers Request to Join Community (i.e. Request to Register with Community) Community Administrator Approves Provider's Request SP Provider Requests to Register the Application with Community Community Administrator Approves the Request of Application Registration SP and IdP in the same community setup Trust Relationship through Request and Approval Process. Note: One Organization can own Community, SP, and IdP at the same time. To make it easier to be illustrated, this document assumes that the Community, SP, and IdP are owned by different Organizations. 3. Administrator Features 3.1. Organization Invitation and Registration 3.1.1. Description Communities and Providers are owned by Organizations in TIB. In order to create Communities and Providers, Organization must be registered in TIB first. The Organization registration process starts with TIB Administrator (Covisint Support team) or Community Administrator (Community Owner) sending out invitation from TIB. The registrant receives the invitation through email, follows the url in the email to the TIB registration web site. The registrant creates organization and user (the registrant) profile and submit the registration request. The request will be routed to TIB Administrator who will approve or reject the request. After the request is approved, the new organization will be created in TIB. In addition, the user account of the registrant will be created. By default, the registrant will be the first Security Administrator of the Organization, who can invite additional Admin users to the Organization, grant or revoke Administrator roles to or from Admin users in the same organization. Page 6 of 55
3.1.2. Process Map Figure 2 Organization Invitation and Registration 3.1.3. Example Screenshot Figure 3 Select Invite Organization to Community from the Communities menu Page 7 of 55
Figure 4 Invite a new organization by entering their email address. A personalized invitation or email message can be created at this time. Figure 5 An email will be sent to the recipient, and the Community dashboard will display Page 8 of 55
Figure 6 Invitee receives the above email message, and clicks on the hyperlink Figure 7 Invitee is asked to accept administrative role for their organization Page 9 of 55
Figure 8 Invitee enrolls their organization. Provider access options can be completed at this time, including the upload of Terms & Conditions Figure 9 Invitee registers their personal information Page 10 of 55
Figure 10 Invitee registers for TIB credentials Figure 11 Invitee must accept the Covisint TIB Terms & Conditions Page 11 of 55
Figure 12 Invitee must specify why they are requesting access to the community Figure 13 Request is put into queue for administrative approval Page 12 of 55
Figure 14 TIB Admin reviews pending Organization request and approve or reject a request by clicking the link. 3.2. Organization Management 3.2.1. Description A Security Administrator of an Organization can edit the profile and setting of the organization, manage the profile and role grant of admin users in the organization, invite new admin users to join the organization, and approve / reject admin user registration request. Page 13 of 55
3.2.2. Process Map Figure 15 Security Administrator Manages the Organization Page 14 of 55
3.2.3. Example Screenshots Figure 16 Security Admin edits Organization settings Figure 17 Security Admin invites others to join the organization Page 15 of 55
Figure 18 Invitee receives the invitation Email, clicks the url link to start the registration Figure 19 Invitee types in invite ID and Pin. Then finishes the registration process Page 16 of 55
Figure 20 Security Admin approves / rejects admin registration request Figure 21 Security Admin search for admin user, clicks on a user ID to manage the account Page 17 of 55
Figure 22 Security Admin update the admin user's account Figure 23 Security Admin search for admin user, clicks on a user ID to manage the roles Page 18 of 55
Figure 24 Security Admin update the admin user's role grants 3.3. Community Creation 3.3.1. Description A TIB Administrator from Covisint will create Community in TIB. The TIB Administrator needs to pick an Organization as the owner of the Community while creating the Community. After the Community is created, a Security Administrator from the owning Organization needs to assign the Community Administrator Role to one or more admin user(s) in the Organization, who will act as the owner of the Community to manage the Community, invite Providers into the Community, approve registration request from Providers. There are two access options for a Community: a) One request from an Organization covers all the providers and applications owned by the Organization; b) Individual request is needed for each provider and application owned by an Organization. Page 19 of 55
3.3.2. Process Map Figure 25 Select Manage Identity Providers from the Providers menu 3.3.3. Example Screenshots Figure 26 TIB Administrator creates new Community 3.4. Identity Provider Registration and Management 3.4.1. Description In order to create a new Identity Provider (IdP), a Security Administrator from the owning Organization needs to assign the Provider Administrator and Community Administrator Role to one or more admin user(s) in the Organization, who will create, manage the IdP and approve registration request from other Providers in the same Community. The registration process is used to submit all the information required to identify and integrate the IdP with Covisint s TIB service. Page 20 of 55
3.4.2. Process Map Figure 27 Provider Administrator creates new IdP 3.4.3. Example Screenshots Figure 28 Under Identity Provider tab in the Manager Provider page, click on Create New IDP Configuration Page 21 of 55
Figure 29 Add Identity Provider, Step 1 Figure 30 Adding an Identity Provider using an existing meta data file Page 22 of 55
Figure 31 Adding Identity Provider, Step 2, after importing configuration from meta data file Figure 32 Adding an Identity Provider, Step 3, configuring TIB-to-IDP attribute mappings Page 23 of 55
Figure 33 Adding an Identity Provider, manual configuration The following figures show examples of the screenshots that will be displayed while managing an existing Identity Providers. Page 24 of 55
Figure 34 Select an IdP by clicking its hyperlink in the list of available IdPs Figure 35 Viewing the configuration of an existing IdP Page 25 of 55
Figure 36 Uploading or pasting in a new certificate for the IdP Figure 37 Viewing the attribute mappings for an existing IdP Page 26 of 55
Figure 38 Adding a new attribute map for an existing IdP Figure 39 Save changes Page 27 of 55
3.5. Service Provider Registration and Management 3.5.1. Description In order to create a new Service Provider (SP), a Security Administrator from the owning Organization needs to assign the Provider Administrator and Community Administrator Role to one or more admin user(s) in the Organization, who will create, manage the SP and approve trust relationship request from other Providers in the same Community. The registration process is used to submit all the information required to identify and integrate the SP with Covisint s TIB service. 3.5.2. Process Map Provider Administrator Create Service Provider (SP) Logins into TIB, Clicks on Manage Provider -> Service Provider tab -> Create new SP Configuration Shows the Form of Selecting Federation Protocol Shows the Option of Uploading the Metadata File Shows the Form of SP Configuration Detail Picks the Protocol Optionally Uploads the Metadata File Clicks Next Updates the Configuration Detail Clicks Next Shows the Form of Mapping Attributes Between TIB and the SP Creates the Service Provider Displays Confirmation Message, and the List of Existing SP Adds Attribute Mappings Clicks Save Figure 40 Provider Administrator creates new SP 3.5.3. Example Screenshots The following figures show examples of the screenshots that will be displayed while registering a new Service Provider. Page 28 of 55
Figure 41 Under Service Provider tab in the Manager Provider page, click on Create New SP Configuration Figure 42 Add Service Provider, Step 1 Page 29 of 55
Figure 43 Adding an Service Provider using an existing meta data file Figure 44 Adding Service Provider, Step 2, after importing configuration from meta data file Page 30 of 55
Figure 45 Adding Service Provider, Step 3, configuring SP-to-TIB attribute mappings Figure 46 Save Changes 3.6. Export MetaData 3.6.1. Description Provider metadata can be exported into.xml files in order to upload into remote end points that need to connect to the ID-Broker service. 3.6.2. Example Screenshot Page 31 of 55
Figure 47 Click on the Export Metadata icon of a Provider from the Manage Provider screen Figure 48 Click the Open with radio button to view the metadata in an XML editor Page 32 of 55
Figure 49 Viewing the metadata Figure 50 Click the Save File radio button to save the metadata as an XML file Page 33 of 55
3.7. Manage Provider Status 3.7.1. Description 3.7.2. Example Screenshots The following figures show examples of the screenshots that will be displayed while suspending an existing Provider. Figure 51 Providers can be suspended by clicking the Suspend button Page 34 of 55
Figure 52 Providers can be reactivated or removed once suspended 3.8. Manage Certificates 3.8.1. Description This feature gives TIB Administrators the ability to install new or updated certificates and remove expired certificates for the Providers over which they have administrative control. The interface allows certificates to be imported from standard X.509.crt files, or pasted into a textarea box. Also, certificate validation files can be exported from this interface. 3.8.2. Example Screenshot The following figures show examples of the screenshots that will be displayed while creating new certificates. Page 35 of 55
Figure 53 Click on the Add Certificate button in the Encryption section of a SP, or Page 36 of 55
Figure 54 Click on the Add Certificate button in the Digital Signature section of an IdP Figure 55 Paste the certificate text into the text box, or import from a file Page 37 of 55
Figure 56 Importing a certificate from a file Page 38 of 55
Figure 57 or paste the certificate into the text box The following figures show examples of the screenshots that will be displayed while managing existing certificates. Figure 58 From the Manage Provider page, click on the Certificate tab Page 39 of 55
Figure 59 Remove an existing certificate by clicking the trash can icon in front of it, or Figure 60 Clicks on the hyperlink of the certificate to view the detail of the certificate Page 40 of 55
Figure 61 Click the Download button to save the certificate into a file Figure 62 Saving a certificate as a file Page 41 of 55
3.9. Service / Application Registration 3.9.1. Description A Service Registration is used to register a Service (Application) with TIB. The registration process is used to associate the service with an Organization, identify the Service Administrator, identify the SP that will be used to support the service, and to submit the information required to identify service. 3.9.2. Process Map Figure 63 Create new Application 3.9.3. Example Screenshots Figure 64 Application Administrator clicks on Add New Application Page 42 of 55
Figure 65 Fills out the form of creating new application and clicks Save Figure 66 New application has been created 3.10. Providers Join Community 3.10.1. Description In order to setup trust relationship between SPs and IdPs, the Providers have to join the same Community. There are two ways for a Provider to join a Community - through request and approval, or invite and registration. Page 43 of 55
A Provider (IdP or SP) Administrator can send request to join a Community. The Community Admin review and approve / reject the request. Upon the approval of the request, the Provider will became a member of the Community. A Community Administrator can send out invitation to the Organization that owns Providers. The invitation is sent out through email. There is a url, a invitation key, and a pin in the email. A Provider Administrator from the Organization that receives the invitation follows the url, use the invitation key and pin to register the Provider(s) that the Organization owns with the Community. With valid invitation key and pin, the Provider(s) that the Providers Administrator picks will be automatically added to the Community after the registration is successfully submitted. 3.10.2. Process Map Figure 67 Provider join community through request and approval process Figure 68 Provider join community through invite and registration process Page 44 of 55
3.10.3. Example Screenshots Request and approval process: Figure 69 Provider Admin clicks on Join Community and see the communities can join Figure 70 Provider Admin reviews the community information, clicks Register link Page 45 of 55
Figure 71 Provider Admin reviews the summary of the request, clicks Submit Figure 72 Request is submitted, pending for approval Page 46 of 55
Figure 73 Requests shows up in Community Admin's pending request list Figure 74 The Provider's status in the Community is Active after the request is approved Page 47 of 55
Invite and registration process: Figure 75 Community Admin picks the organization to invite and clicks Send Invitation Figure 76 Organization Admin receives the invitation email, logs into TIB to register with the community 3.11. Application Join Community 3.11.1. Description An Application in the SP needs to join the Community in order to make it accessible to the users from trusted IdP. The pre-condition is that the SP that owns the Application is already in the Page 48 of 55
Community. An Application Administrator can send request to join a Community. If the Community is configured to require approval for each Application, the request will be routed to the Community Admin's queue for approval. Otherwise, the request will be automatically approved. Upon the approval of the request, the Application will became available to the trusted IdPs in the same Community. 3.11.2. Process Map Figure 77 Application join community 3.11.3. Example Screenshots Page 49 of 55
Figure 78 Application join a Community Figure 79 Pick a Community, then click Application tab. Click Register link Page 50 of 55
Figure 80 Pick a Community, then click Application tab. Click Register link Figure 81 Request is approved, the Application's Status in Community is Active Page 51 of 55
3.12. Setup Trust Relationship between Providers 3.12.1. Description After the IdP and SP have joined the same Community, trust relationship can be setup between them. Providers need to send request for relationship to each other. After both sides approve the request, the trust relationship between the two Organizations will be setup. 3.12.2. Process Map (SP) Provider Administrator Request for Provider Trust Relationship Logins into TIB, Clicks on Communities -> Manage Community, Picks the Community from the Dropdown, Clicks Identity Provider tab Shows the List of IdP available for Requesting Trust Relationship Clicks on Request Relationship link of one IdP Shows the Summary of the Request Reviews and Submits the Request Persists the Request Shows the Confirmation Message (IdP) Provider Administrator Approve Provider Trust Relationship Request Logins into TIB, Clicks on Communities -> Pending Community Requests Shows the List Request Under the Provider Trust Relationship tab Reviews the Detail of a Request, Clicks Approve Sets the Trust Relationship Between the Providers in Pending state Displays Confirmation Message (IdP) Provider Administrator Request for Provider Trust Relationship Logins into TIB, Clicks on Communities -> Manage Community, Picks the Community from the Dropdown, Clicks Service Provider tab Shows the List of SP available for Requesting Trust Relationship Clicks on Request Relationship link of one SP Shows the Summary of the Request Reviews and Submits the Request Persists the Request Shows the Confirmation Message (SP) Provider Administrator Approve Provider Trust Relationship Request Logins into TIB, Clicks on Communities -> Pending Community Requests Shows the List Request Under the Provider Trust Relationship tab Reviews the Detail of a Request, Clicks Approve Sets up the Trust Relationship Between the Providers (if the request from SP to IdP has been approved already) Displays Confirmation Message Figure 82 Setup trust relationship between Providers 3.12.3. Example Screenshots Page 52 of 55
Figure 83 SP request trust relationship with an IdP Figure 84 Review request summary and submit Page 53 of 55
Figure 85 Confirmation message. The request is Pending for Approval Figure 86 IdP Admin review the pending request and Approve it Page 54 of 55
Figure 87 IdP request trust relationship with an SP Figure 88 SP Admin review the pending request and Approve it Page 55 of 55