We have more integration options: see our overview.
Security Assertion Markup Language (SAML) is the standard for secure single-sign-on (SSO), and is the basis of SSO products from Okta, OneLogin, Microsoft, Bitium, Ping Identity, and more. Easygenerator fully supports the SAML v2.0 standard, making your Easygenerator accounts more secure.
Some of the benefits of SAML are:
- No vendor lock-in - Since SAML is an Open standard you can switch vendors with no impact on the user's experience;
- User passwords never cross the corporate firewall (in the case of IdP initiated SAML SSO);
- Reusable - Several SPs can connect one IdP for authentication, and one SP can connect to several IdPs;
- Better accessibility;
- Eliminates additional credentials, which minimizes opportunities for identity theft;
- Eliminates phishing opportunities by reducing the number of times a user needs to log in;
- Eliminates the administration and development cost of implementing a proprietary SSO solution.
Note: SAML Single Sign On is available only within the Enterprise plan.
Here are some basic terms to help you in this guide:
- Identity Provider (IdP): The software/service that verifies the identity of your users. For example, Okta, OneLogin, Active Directory, etc.
- Service Provider (SP): Easygenerator.
- Metadata URL: URL for the provider’s metadata. Both the IdP and the SP should have a Metadata URL. Here are Easygenerator metadata URLs:
- Easygenerator IdP metadata URL: https://live.easygenerator.com/saml/idp
- Easygenerator SP metadata URL: https://live.easygenerator.com/saml/sp
- Issuer (Entity ID): A unique string that identifies the provider issuing a SAML request. According to the SAML specification, the string should be a URL, though it is not required by all providers.
- Consumer URL: The Easygenerator (SP) URL that will receive SAML requests from your IdP.
- IdP SSO target URL: The IdP URL that will receive SAML requests from Easygenerator (the SP).
Example use of SAML Single-Sign-On:
- The user logs in at example.com;
- The user got authenticated against an identity provider at idp.example.com;
- The user now tries to log in to live.easygenerator.com;
- live.easygenerator.com sends a samlp:AuthnRequest to the idp.example.com and asks to authenticate the user;
- Since the user is already authenticated, the idp.example.com sends a SAML assertion saying the user is authenticated;
- live.easygenerator.com lets the user log-in without asking for identity information again.
SAML Use cases (Web-based SSO with HTTP POST binding):
The following flow diagram shows a simple deployment of SAML 2.0 web-based Single-Sign-On using the HTTP POST binding for the Service Provider’s requests, and Identity Provider’s response.
- The principal requests a target resource at the service provider
- The service provider sends a POST via user agent to the SSO Service at the identity provider
- The user agent issues a POST request with the SAML 2.0 AuthnRequest to the SSO service at the identity provider
- The SSO service validates the request and responds with a document containing an HTML form. The HTML form has a hidden parameter called SAMLResponse which contains the <samlp:Response>
- Request the Assertion Consumer Service (ACS) at the Service Provider. The <samlp:Response> is sent along to the ACS
- The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource
- The user agent requests the target resource at the service provider
- Since the user is authenticated, SP returns the resource to the user