SAML and Federation

 SAML (from PingIdentity)

SAML (Security Assertion Markup Language) is an open authentication standard that makes single sign-on (SSO) to web applications possible. SSO allows users to sign on to multiple web-based applications and services using a single set of credentials. Designed to simplify user sign-on experiences, SAML is most widely used in enterprise organizations and allows users to access applications and services that they pay for. 


Most importantly, SAML sign-on experiences are secure because user credentials are never transmitted. Instead, they’re handled by identity providers (IdPs) and service providers (SPs):
 

  • The IdP stores all of the user credentials and information necessary for authorization and provides it to the SP, when requested. It's the IdPs’ job to say, “I know this person, and they should be able to access these resources.” 
     

  • The SP hosts the applications and services that users want to access. These applications or services might include email platforms, such as Google or Microsoft Office, or communications apps, such as Slack or Skype. It’s the SPs’ job to say, “You can access these applications or services for a specified period of time without having to sign-on again.”

When users attempt to access these applications or services, the SP asks the IdP to verify their identities. The IdP issues SAML assertions, or tokens, which contain the information necessary to confirm user identities, including the time the assertions were issued and the conditions that make the assertions valid. After they’re received, the SP gives users access to the resources they requested.


You can compare a SAML sign-on experience to that of checking out a library book:
 

  • You find a book that you want to read and take it up to the counter.
     

  • The librarian asks if you have your library card. You say, "No, I just moved to town." The librarian says, "Well, I can't let you check out the book until you have a library card. Go over to the desk and have the assistant librarian make you a card so that we have a record of who you are."
     

  • You go to the desk and give the assistant librarian your driver's license. The assistant librarian enters your name and address into the library system, creates the card, and hands it to you. You take the card back to the librarian, who scans it and checks out the book for you. You can now take the book home for a specified period of time.

In this scenario, you authenticate with the assistant librarian (IdP) by showing them your ID. Then, the assistant librarian (IdP) creates the card using your information. When you present the library card to the librarian (SP), they use the card to check out the book for you.


This short video provides additional examples of how SAML is used to quickly and securely connect employees, partners, and customers to an organization's digital resources.
 

 

How does SAML work?


SAML is an XML-based framework, which means it's extremely flexible, can be used on any platform, and can be transmitted by a variety of protocols including HTTP and SMTP. Federation partners can choose to share whatever information they want in a SAML assertion as long as the information can be represented in XML. 


A typical SAML authentication process works this way:




  

  1. The user signs on and requests access to the SP’s target web application or service.

  2. The SP requests user authentication information from the IdP.

  3. The IdP creates a SAML-formatted, digitally signed response that authenticates the user. This response can be in the form of a SAML assertion or a SAML token. The response can also include information about user privileges.

  4. The IdP signs the assertion and sends it to the SP.

  5. The SP retrieves the assertion, ensures that it’s valid, and authenticates the user.

  6. The user accesses the service provider’s application or service.

 

SAML sign-on experiences are secure because user credentials are never transmitted. SAML assertions, or tokens, are used instead.
 

What are SAML assertions?


SAML assertions are XML documents sent from an IdP to an SP that identify users, contain pertinent information about them, and specify their privileges in the target application or service. These messages also provide assurances that the information is valid and specify how long users can access these resources without having to sign-on again.


SAML assertions are primarily used for authentication purposes, but they can also include authorization information:
 

  • Authentication assertions: Identify users and provide sign-on information, including the time sign-on occurred and the method used to authenticate.

  • Attribute assertions: Contain user attribute information that exists in both the IdP and SP directories and is matched during the authentication process.

  • Authorization assertions: Indicates whether the user is authorized to access the application or service. 

SAML is widely used in enterprise organizations to share identity information between existing IAM systems and web applications. The ways that these processes are implemented depend on the ways sign-on processes are initiated -- either through the IdP or the SP.

 

IdP-initiated SSO


IdP-initiated SSO is often found in workforce solutions. The steps involved in this type of process are outlined in the following diagram.
 

 

  1. A user signs on to their system with a username and password and is presented with an application catalog that displays icons representing the web-based applications and services they can access. 

  2. The user clicks an icon to access one of those applications or services. 

  3. The IdP creates and signs an SAML assertion that includes information about the user’s identity, along with any other attribute information that the IdP and SP agreed to share to authenticate users.

  4. The IdP either sends the assertion to the SP through a browser or sends a reference to the assertion that the SP can use to securely retrieve the assertion.

  5. The SP validates the signature to ensure that the SAML assertion really came from its trusted IdP and that none of the values in the assertion have been modified. It also extracts the identity, attribute, and authorization information it needs to determine whether access should be granted and which privileges the user will have.

  6. Users access the application or service.
     

 

SP-initiated SSO


SP-initiated SSO begins when a user tries to access an application or service directly, instead of authenticating through the IdP first. The steps involved in this type of process are outlined in the following diagram.
 

 

  1. The user attempts to access the application or service.

  2. The SP redirects the user back to the IdP to be authenticated and provides the user with a resource URL to access the application or service after they’re authenticated.

  3. The SP determines which IdP the SP should use to authenticate the user. Common methods include:

    The SP might ask the user for their email address and use the domain of the email, such as bill@pingidentity.com, to identify the appropriate IdP.

    The SP might display a list of IdPs it supports and ask the user to select the appropriate one.

    The resource URL might be specific to one IdP.

    The SP might have placed a cookie containing IdP information in the user’s browser the first time the user successfully signed on from the IDP and will use this information for subsequent access.

  4. The SP redirects the user to the appropriate IdP. 

  5. The IdP authenticates the user’s identity.

  6. The IdP creates and signs an XML-based SAML assertion that includes information about the user’s identity, along with any other attribute information that the IdP and SP agreed to share to authenticate users.

  7. The IdP either sends the assertion to the SP through a browser, or sends a reference to the assertion that the SP can use to securely retrieve the assertion.

  8. The SP validates the signature to ensure the SAML assertion really came from its trusted IdP and that none of the values in the assertion have been modified. It also extracts the identity, attribute, and authorization information it needs to determine whether access should be granted and which privileges the user will have.

  9. Users access the application or service.
     

SAML is only used for web applications


Because it’s an XML framework, SAML is extremely versatile. Many different SSO connections with different identity federation partners can be supported with a single implementation, which is why it’s often used in business and enterprise organizations.


However, SAML only supports SSO to browser-based applications and services. It does not support SSO for mobile applications or applications that access resources through the API.

Comments

Post a Comment

Popular posts from this blog

VMware fix for Invalid manifest and ova file import failed errors

Image
Recently we got a OVA file for a virtual machine. The vendor instructions were to import the ova file in vmware Workstation, Player for Windows/Linux, Fusion for Mac, and VirtualBox as well.  The instructions were to take the available package and launch the VM with VMware workstation. The package contained  Module.mf, Module.ovf and Module-disk.vmdk and a Module.ova file. The .mf and .ovf file were 2 KB each whereas the vmdk was several gigs. The package also contained a Module.ova file which was several gigs as well. OVF           Open Virtualization Format MF             Manifest file VMDK       Virtual Machine Disk OVA           Open Virtualization Appliance The ovf file is a xml file that contains metadata for the ovf package The mf file contains the SHA1 hash codes of all files in the package The vmdk file is the disk image of the virtual machine,  VMware Workstation or VirtualBox. (vmdk format was originally developed by VMware and is an open format now). All of
Read more

SOAPUI - import certificate

Image
Note: SoapUI has two versions, one is open source and second Professional version. The open source can be download here . (confirmed link 12/19/2018). SSL Handshake issue:   There is an Issue in SoapUI version 5.3.0 (and 5.2.0 version) with SSL handshake error. It was resolved by updating below in vmoptions file ( refer here ). However, the error that shows up while trying to load wsdl is "Error loading WSDL" as below The fix is to Enable TLS 1.2 protocol for SOAP/REST calls in SoapUI, by ammending the vmoptions file to add the directive for TLS as (-Dsoapui.https.protocols=TLSv1.2). Refer here . Update: Version 5.5.0 does not have this issue. If you are on 5.3.0 better upgrade to 5.5.0 which is available now (Feb 2019). I had above issue as well as another issue reaching to https endpoint. Upgrade to 5.5.0 resolved issue. Select "Check for updates" under the Help menu and you will get option for upgrade. Select upgrade current version and accept all defaul
Read more

Centrally Managed Users (CMU) - New Feature in Oracle Database 18c

Image
Centrally Managed Users (CMU) Centrally Managed Users or CMU is a new feature introduced since Oracle DB 18c which allows simplified database user management through integration with Microsoft Active Directory (AD). Beginning with Oracle Database release 18c, version 18.1 and later supports direct integration with Microsoft Active Directory (AD) using the new centrally managed users capability. CMU allows the Oracle database to perform user authentication and authorization directly against AD. Benefits of CMU With centrally managed users, users accessing the database can be centrally managed to improve an organization's security posture. An enterprise user (a user in Microsoft Active Directory) can be exclusively mapped to a database account, or many enterprise users (in an Microsoft Active Directory group) can be mapped to a shared account in the database. Microsoft Active Directory groups can also be mapped to a database global role, which provides users with additional privilege
Read more