Configuring Single Sign-On (SSO) via Identity Management | MuleSoft Mysore Meetup #48
- 1. Mysore MuleSoft Meetup 06-July-2024 Configuring Single Sign-On (SSO) via Identity Management 💡
- 2. Organizers Shubham Chaurasia Billennium India Pro Integration Developer Giridhar Meka Sr. Technology Architect linkedin.com/in/giridharmeka linkedin.com/in/shubhamchaurasia1 Priya Shaw LTI MindTree Sr. Software Specialist linkedin.com/in/priya-shaw
- 3. Speaker • Technical Manager & Integration Architect @ Ernst & Young GDS • 13+ Years of experience in Integration & API products in Solutioning & Designs. • Top 2024 MuleSoft Mentor • Certified Integration & Platform Architect in MuleSoft • Certifications Rack: 4X MuleSoft & 6X IBM VIJAYARAGHAVAN VENKATADRI
- 4. AGENDA ● Single Sign On (SSO) ● SSO Standards ● OpenID Connect vs SAML 2.0 ● OpenID Connect - Architecture ● Configuring SSO Using OIDC (Demo) ● SAML 2.0 - Architecture ● Configuring SSO Using SAML 2.0 (Demo) ● Mapping IDP Groups with Anypoint Team (Demo) ● Q & A
- 5. Single Sign-On (SSO) • Single Sign-On aka SSO is a social and enterprise solutioned session and user authentication service which enables the user to access multiple application using a common credentials. • SSO is a federated identity management arrangement where identity providers (IDP) enforce the SSO standards. Through the SSO, the IDP provides delegated authorization to the applications on behalf of the user. • Social SSO: Google, Apple, LinkedIn, Facebook, etc. are the popular social organizations which provides SSO services which can be leveraged to use their social media authentication credentials • Enterprise SSO: Microsoft, Ping, Okta, OpenAM etc. are the well known enterprise IDP that enables the end-users to securely access all of the enterprise’s applications.
- 6. Single Sign-On Advantages ● Simplified Password Management. ● Increased Admin Control. ● Efficient Sign-in processes. ● Improved security over cyber attacks. ● Reduced Password Fatigue. ● Fewer help desk requests. ● Requires an IDP ● Mainly limited to web apps. ● Requires extra strong password. ● SSO config plugin should be supported by in-house applications. ● If SSO is compromised, then all the applications are open to attack. Disadvantages
- 7. SSO Standards • Below are the popular standards of SSO i.e. identity protocols which are widely used in Social and Enterprise SSO ○ OpenID Connect (Extension of Open Authorization 2.0) ○ SAML 2.0 (Security Assertion Markup Language) • These protocols are designed to authenticate users and provide user identity data for access control and as a communication method for a user’s identity. • Choosing SAML over OIDC or OIDC over SAML is purely depends on the choice of administrator or security policy defined in an organization to configure SSO. • However, both these protocols are supported by most of the Identity Providers.
- 8. OIDC VS SAML 2.0 OpenID Connect ● OpenID Connect is a new protocol, continuously evolving and it designed with web and mobile applications in mind. ● OpenID is attractive and easier to use and also lightweight compared to SAML (as it requires heavy-weight XML handling) ● However, it is still lagging behind SAML in terms of feature. ● It is matured technology dating from 2005 and used mainly by Enterprise and Government applications. ● SAML has a long track of record of providing a secure means of identity data exchange, so ideally it is trusted in many organization. ● It is also very feature-rich, covering a wide range of identity requirements. SAML 2.0
- 9. OpenID Connect Architecture • OpenID Connect aka OIDC is an identity authentication protocol - extension of Open Authorization 2.0 aka OAuth 2.0. • OAuth 2.0 standardize the process of authenticating and authorizing users when they try to access the digital services. ○ Authentication - verifying the user who they say they are. ○ Authorization - granting the access to the users for the resources they intend to access through Access Token and a refresh token. • OIDC is used to provide single sign-on and identity data of an end user through ID tokens which is a JSON Web Signature Token (JWT). • When it comes to OIDC, the component nomenclatures are little different than OAuth 2.0.
- 10. OpenID Connect Architecture • Users: People or services that seek access to the application without providing the credentials. • Relying Parties: The application to use OpenID providers to authenticate the users using the tokens. • OpenID Providers: The application for which a user already has an account. They will authenticate the user and pass that information to relying parties. • ID Token: Contains identity data including the outcome of the authentication process, an identifier for the user, and information about how and when the user is authenticated.
- 11. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider
- 12. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource
- 13. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource Authorization Code Request
- 14. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource Authorization Code Request HTTP Redirect Authorization Endpoint Along with scope, client creds of RP
- 15. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource Authorization Code Request HTTP Redirect Authorization Endpoint Along with scope, client creds of RP Request user to authenticate & Consent 1. Authenticate User (Return OP Session ID) 2. Confirm Consent (Only first Time) OP Session established
- 16. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource Authorization Code Request HTTP Redirect Authorization Endpoint Along with scope, client creds of RP Request user to authenticate & Consent 1. Authenticate User (Return OP Session ID) 2. Confirm Consent (Only first Time) OP Session established Auth Code Response (Call Back URL) Generate Authorization Code
- 17. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource Authorization Code Request HTTP Redirect Authorization Endpoint Along with scope, client creds of RP Request user to authenticate & Consent 1. Authenticate User (Return OP Session ID) 2. Confirm Consent (Only first Time) OP Session established Auth Code Response (Call Back URL) Generate Authorization Code HTTP Redirect Call Back URL Auth Code Status
- 18. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource Authorization Code Request HTTP Redirect Authorization Endpoint Along with scope, client creds of RP Request user to authenticate & Consent 1. Authenticate User (Return OP Session ID) 2. Confirm Consent (Only first Time) OP Session established Auth Code Response (Call Back URL) Generate Authorization Code HTTP Redirect Call Back URL Auth Code Status Access token Request Token Endpoint Auth Code, Client ID & Secret, Scope
- 19. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource Authorization Code Request HTTP Redirect Authorization Endpoint Along with scope, client creds of RP Request user to authenticate & Consent 1. Authenticate User (Return OP Session ID) 2. Confirm Consent (Only first Time) OP Session established Auth Code Response (Call Back URL) Generate Authorization Code HTTP Redirect Call Back URL Auth Code Status Access token Request Token Endpoint Auth Code, Client ID & Secret, Scope 1. Validate Client Cred & Auth Code 2. Generate Access & Refresh + ID Tokens Access + ID Tokens
- 20. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource Authorization Code Request HTTP Redirect Authorization Endpoint Along with scope, client creds of RP Request user to authenticate & Consent 1. Authenticate User (Return OP Session ID) 2. Confirm Consent (Only first Time) OP Session established Auth Code Response (Call Back URL) Generate Authorization Code HTTP Redirect Call Back URL Auth Code Status Access token Request Token Endpoint Auth Code, Client ID & Secret, Scope 1. Validate Client Cred & Auth Code 2. Generate Access & Refresh + ID Tokens Access + ID Tokens Request User Information User Info Endpoint Access Token
- 21. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource Authorization Code Request HTTP Redirect Authorization Endpoint Along with scope, client creds of RP Request user to authenticate & Consent 1. Authenticate User (Return OP Session ID) 2. Confirm Consent (Only first Time) OP Session established Auth Code Response (Call Back URL) Generate Authorization Code HTTP Redirect Call Back URL Auth Code Status Access token Request Token Endpoint Auth Code, Client ID & Secret, Scope 1. Validate Client Cred & Auth Code 2. Generate Access & Refresh + ID Tokens Access + ID Tokens Request User Information User Info Endpoint Access Token 1. Validate Access Token 2. Prepare Claims User Information Response
- 22. OpenID Connect Architecture Browser Relying Party (RP) OIDC Provider Request Resource Authorization Code Request HTTP Redirect Authorization Endpoint Along with scope, client creds of RP Request user to authenticate & Consent 1. Authenticate User (Return OP Session ID) 2. Confirm Consent (Only first Time) OP Session established Auth Code Response (Call Back URL) Generate Authorization Code HTTP Redirect Call Back URL Auth Code Status Access token Request Token Endpoint Auth Code, Client ID & Secret, Scope 1. Validate Client Cred & Auth Code 2. Generate Access & Refresh + ID Tokens Access + ID Tokens Request User Information User Info Endpoint Access Token 1. Validate Access Token 2. Prepare Claims User Information Response Validates sub matches ID Token Provide Access to Resources
- 23. Demo Configuring SSO Using OIDC (Demo)
- 24. SAML 2.0 Architecture • Security Assertion Markup Language 2.0 (SAML 2.0) is an XML based protocol that uses security tokens containing assertions to pass information about the end user between the SAML authority (Identity Provider) and a SAML Consumer (Service Provider). • An assertion is a package of information supplied by the SAML authority. It encompases many statement and below are two key statement to come across. ○ Authentication Statement: The assertion subject was authenticated by a particular means of time. ○ Attribute Statement: The assertion subject is associated with the supplied attributes. • There are key elements within the <saml:assertion>
- 25. SAML 2.0 Architecture • <saml:Issuer>: Unique identifier of the identity provider • <ds:Signature>: Digital Signature for signing the Assertion • <saml:Subject>: Authenticated information about the end user • <saml:Conditions>: The time period and the condition that the assertion to be considered as valid • <saml:AuthnStatement>: The act of authentication at the identity provider. • <saml:AttributeStatement>: The multi-valued attribute about the end user.
- 27. OpenID Connect Architecture User Agent Service Provider Identity Provider
- 28. OpenID Connect Architecture User Agent Service Provider Identity Provider Request Resource
- 29. OpenID Connect Architecture User Agent Service Provider Identity Provider Request Resource Redirect to SSO Service SP generates SAML Authentication request - will be in query parameter of HTTP redirect
- 30. OpenID Connect Architecture User Agent Service Provider Identity Provider Request Resource Redirect to SSO Service Request SSO Service SP generates SAML Authentication request - will be in query parameter of HTTP redirect
- 31. OpenID Connect Architecture User Agent Service Provider Identity Provider Request Resource Redirect to SSO Service Request SSO Service SP generates SAML Authentication request - will be in query parameter of HTTP redirect Request user to authenticate & Consent IP authenticate user and validate request
- 32. OpenID Connect Architecture User Agent Service Provider Identity Provider Request Resource Redirect to SSO Service Request SSO Service SP generates SAML Authentication request - will be in query parameter of HTTP redirect Request user to authenticate & Consent IP authenticate user and validate request - saml authentication response generated and sent in XHTML Respond with xHTML form
- 33. OpenID Connect Architecture User Agent Service Provider Identity Provider Request Resource Redirect to SSO Service Request SSO Service SP generates SAML Authentication request - will be in query parameter of HTTP redirect Request user to authenticate & Consent IP authenticate user and validate request - saml authentication response generated and sent in XHTML Respond with xHTML form Call back to Assertion Consumer Service URL
- 34. OpenID Connect Architecture User Agent Service Provider Identity Provider Request Resource Redirect to SSO Service Request SSO Service SP generates SAML Authentication request - will be in query parameter of HTTP redirect Request user to authenticate & Consent IP authenticate user and validate request - saml authentication response generated and sent in XHTML Respond with xHTML form HTTP POST to Assertion Consumer Service URL Redirect to the target resources Process Response and security context is created for the user
- 35. Demo Configuring SSO Using SAML 2.0 (Demo)
- 36. Mapping IP groups with Anypoint Teams • Though the users are authenticates using SSO, the required permissions for the user must be provided in the Anypoint Platform. • Providing the permissions manually for each user is not a recommended approach. So, the users has to be grouped under respective teams with the right permissions assigned as below. ○ API Developer ○ API Designer ○ API Administration • So, while the SSO being enabled for any user, the corresponding group has to be created in the Identity Provider which will map with the Anypoint Teams. • So when logs in, they will have the right permissions in the Anypoint Platform.
- 37. Demo Mapping IDP Groups with Anypoint Team (Demo)
- 38. Thank you
Editor's Notes
- Thank you.