<Project Name>Project Management PlanVersion:1.0Error! Unknown document property name.
NIH Login Service Implementation details
Version Number: 1.0
Version Date: 10/23/2017
Revision Date:Error! Unknown document property name. Page 1 of 23
Review of the Mailbox Moves for CIT_OCIO Early Adopters Wave 1 - v1.0
NIH Login Service Implementation details
Revision history
Version / Date / Name of Author / Summary of ChangesV1.0 / 10/23/2017 / Sulochana Nunna / Initial Version
TABLE OF CONTENTS
Purpose of Document
Assumptions
Technical Overview
Supported integration models:
Webagent
Secure Proxy Server
Federation
Webservices
Supported Authentication schemes
Userid/password authentication
Certificate based authentication
Kerberos authentication
Federation – WAYF
Multi Factor authentication
Level of Effort
Siteminder policy objects best practices
Server setup Run books
CUSTOM intigrations
Purpose of Document
This document describes technical implementation details of the NIH Login service for internal use.
Assumptions
This document covers the basic implementation details of the NIH Login service
Technical Overview
Supported integration models:
Webagent
Secure Proxy Server
Federation
There are three types of federation protocols supported currently:
- SAML2.0 (Both as a service provider and Identity provider)
- OAuth (As a Service provider)
- WSFederation (As a Service provider)
SAML2.0:
oAuth:
WS-Federation:
Webservices
The CA Single Sign-on authorization and authentication web services are part of the CA Access Gateway installation.
One or more agents to protect target applications against which callers authenticate
Realms, user directories, policies, and responses that are required for authentication and authorization
You can use the authentication and authorization web services to support an application that is not otherwise protected. A free-standing application on a mobile phone, for example, can authenticate a user when the appropriate CA Single Sign-on objects are available.
These web services support the SOAP 1.2 protocol and the HTTP-based RESTful architecture using the POST method. The authentication and authorization web services provide the following functionality:
login -- Authenticates and returns a session token when the authentication is successful.
Note: If the Enable User Tracking option is enabled, the response contains an identity token additionally.
blogin -- Authenticates and verifies whether the login is successful; does not return a session token.
logout -- Logs out the user or group of users.
authorize -- Returns an authorization status message and a refreshed session token.
Supported Authentication schemes
Userid/password authentication
For forms-based authentication, credentials are collected by the Forms Credential Collector (FCC) process. The default extension for FCC files is (naturally enough) 'FCC'. The FCC process files are composed in a simple mark-up language that includes HTML and some custom notation. This file contains the custom form definition and additional information that the FCC uses to process HTML forms-based authentication. The FCC extracts credentials that a user enters in the custom form generated from the FCC file. For example, the Web agent is installed with a form called login.fcc, which we can customize and use for login purposes.
Certificate based authentication
Kerberos authentication
Federation – WAYF
Multi Factor authentication
CUSTOM intigrations
Cognos Integration:
Cognos intigration.docx
OWA Integration:
AWS Integration:
ITAS PIV Integration:
and AWS federation setup.docx
Page1 of 10