Instruction how to configure SAML2 Authentication in erwin Web Portal application ?

Please check detail instruction using this URL:

http://metaintegration.com/Products/MIMM/OEM/erwin/Help/UserGuide/#!Documents/saml2authenticationworkflow.html

an identity provider (abbreviated IdP or IDP) is a system entity that creates, maintains, and manages identity information for principals while providing authentication services to relying applications within a federation or distributed network. In the ADFS case, the IDP URLs are usually in the form of https://your.adfs.server/adfs/ls.

Single Sign on URL example:

https://login.microsoftonline.com/0333233f1-4f69-abef-c46d541d019d/saml2

For the attribute mapping:

Attribute statement in the assertion requires to  contain the user attributes First Name, Last Name, Login, Email, Full Name and Department

-Login is the must have, which will be served as the user name within our system. We have seen some customers mapping Login to "NameID" for ADFS.

• Full name is used by the UI to display the user's name.
• Email is needed if the user needs to get notifications.
• Group mapping is needed if they want to map the user to EWP security group(s) at login time. Remember, if you use the automatic group assignment, the all group assignments for the user are re-initialized based upon the mapping each time the use logs in. If you do not have any user group mapping defined, then the user group Guest is assigned (if present) but existing assignments are not initialized (they remain) at login

The workflow process:

1.  An end user clicks on the “Login” button on a metadata management service at meta Integration® Metadata Management (MIMM).

2.  To authenticate the user, meta Integration® Metadata Management (MIMM) generates a SAML Authentication Request and redirects the user to the Okta Single Sign-On URL endpoint with the request embedded. This endpoint is unique for each application within each Okta tenant. Below is the Okta Single Sign-On login window.

3.  Once the user is redirected to Okta they’ll need to enter their Okta credentials, unless they had already authenticated into Okta in a previous session within the same browser. In either case, a successful authentication request will send a POST request to the meta Integration® Metadata Management (MIMM) Assertion Consumer Service, i.e. the meta Integration® Metadata Management (MIMM) Authentication Servlet,  with an embedded SAML response from Okta. At a minimum, the response will:

-       Indicate that it is indeed from Okta and hasn’t been altered, and contain a digital signature proving such. This signature will be verified by meta Integration® Metadata Management (MIMM) using a public key from Okta that was previously stored in the SAML Server Configuration.

-       Indicate that the user has authenticated successfully into Okta

-       Indicate who the user is via the NameID, a standard attribute used in SAML assertions. Besides the NameID attribute, the response may also contain other attributes specified in the User Attribute Mapping. meta Integration® Metadata Management (MIMM) may retrieve the user information from these attributes..

4.  After the assertion is successfully parsed and validated by the meta Integration® Metadata Management (MIMM) Authentication Servlet, the user will then be redirected to the meta Integration® Metadata Management (MIMM) default relay state, e.g., metadata explorer, which is usually the same page they would wind up if they were to simply log into the MIMM with a username and password.