Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a OpenId Connect Protocol
Semelhante a OpenId Connect Protocol (20)
Mais de Michael Furman
Último
Último (20)
OpenId Connect Protocol
- 1. Adopting OpenID Connect Protocol Michael Furman Security Architect
- 2. What will we see today? • OpenID Connect Overview • SAML and other protocols vs OpenID Connect • Adopting OpenID Connect Protocol • Keycloak Overview • Advanced Keycloak Features
- 3. About Me • 20+ years in software engineering • 10+ years in application security • 3+ years Tufin Lead Security Architect • www.linkedin.com/in/furmanmichael/ • ultimatesecpro@gmail.com • Read my blog https://ultimatesecurity.pro/ • Follow me on twitter @ultimatesecpro • I like to travel, read books and listen to music.
- 4. About Tufin • Market Leader in Security Policy Orchestration – Established in 2005 – Main offices in Ramat-Gan and Boston • Used by over 2,000 enterprises, including 40 Fortune 100 companies • We are constantly growing! – Please send me your resume.
- 5. OpenID Connect Protocol • Interoperable authentication protocol • Based on OAuth 2.0 family of specifications • Uses REST/JSON message flows http://openid.net/connect/faq/
- 6. • Leading authentication standard • 92% of Azure Active Directory authentications use OpenID Connect. https://twitter.com/ultimatesecpro/status/997399346277740544 OpenID Connect Protocol
- 7. OpenID Connect Providers • Google https://developers.google.com/identity/protocols/O penIDConnect#authenticatingtheuser • Microsoft https://docs.microsoft.com/en-us/azure/active- directory/develop/active-directory-protocols- openid-connect-code
- 8. OpenID Connect Providers • Okta https://developer.okta.com/standards/OIDC/ • PayPal https://developer.paypal.com/docs/integration/dire ct/identity/log-in-with-paypal/ • SalesForce https://developer.salesforce.com/page/Inside_Open ID_Connect_on_Force.com
- 9. OpenID Connect Components • Identity Provider (IDP) - offers user authentication as a service • Relying Party (RP) - outsources its user authentication function to an IDP • Web site • Application
- 10. OpenID Connect Components End User Relying Party (RP) Identity Provider (IDP)
- 11. OpenID Connect Authentication Flow Relying Party (RP) Identity Provider (IDP) 1. Request a resource End User
- 12. OpenID Connect Authentication Flow Relying Party (RP) Identity Provider (IDP) 2. Redirected to IDP End User
- 13. OpenID Connect Authentication Flow Relying Party (RP) Identity Provider (IDP) 3. IDP provides a login page End User
- 14. OpenID Connect Authentication Flow Relying Party (RP) Identity Provider (IDP) 4. User provides credentials. End User
- 15. OpenID Connect Authentication Flow Relying Party (RP) Identity Provider (IDP) 5. IDP authenticates a user End User
- 16. OpenID Connect Authentication Flow Relying Party (RP) Identity Provider (IDP) 6. Redirected to RP with a token ID End User
- 17. OpenID Connect Authentication Flow Relying Party (RP) Identity Provider (IDP) 7. RP accesses IDP to get user information (via REST API) End User
- 18. OpenID Connect Authentication Flow Relying Party (RP) Identity Provider (IDP) 8. RP creates a user session and providers the resource End User
- 19. SAML vs OpenID Connect • Security Assertion Markup Language (SAML) – XML-based protocol – Older protocol: 2005 (SAML2) – High rate of adoption – Designed only for Web-based applications • OpenID Connect – JSON/REST based protocol – Newer protocol: 2014 – Designed to support native apps and mobile applications
- 20. SAML SP-Initiated Flow Diagram from http://docs.oasis-open.org/
- 21. Why would I use SAML? • To support legacy customers (that still use SAML). • Use Keycloak as the bridge
- 22. OpenID vs OpenID Connect • OpenID 2.0 – Uses XML and a custom message signature scheme – Difficult to create interoperable applications • OpenID Connect – Uses standard JSON Web Token (JWT) data structures – Better interoperability
- 23. OAuth 2.0 vs OpenID Connect • OAuth 2.0 is an authorization framework – Provides message flows based on JSON and HTTP https://oauth.net/articles/authentication/ • OpenID Connect is an authentication protocol – Uses OAuth 2.0 flows and services – (Identity, Authentication) + OAuth 2.0 = OpenID Connect
- 24. OAuth 2.0 Authorization Prompt Picture from https://aaronparecki.com/oauth-2-simplified/
- 25. OAuth 2.0 Flow Diagram from https://developers.google.com/identity/protocols/OAuth2
- 26. Why would I use OAuth 2.0? • Oauth 2.0 is a mature protocol • Use it to access to application resources – APIs – …
- 27. How do I adopt OpenID Connect? • Select RP • Select IDP
- 28. How do I select RP? • Certified Relying Party (RP) Libraries – Apache HTTPd server – .NET Nuget Package – Erlang – JavaScript – PHP – Python – … http://openid.net/developers/certified/
- 29. How do I select IDP? • Certified Identity Provider (IDP) Libraries – Gluu Server – MITREid Connect – Keycloak – … http://openid.net/developers/certified/
- 30. Keycloak • Open source Identity and Access Management solution http://www.keycloak.org/about.html • Provides Single-Sign On (SSO)
- 31. RedHat SSO is based on Keycloak • List of RedHat SSO components https://access.redhat.com/articles/2342881 • Let's open https://access.redhat.com/solutions/1472293
- 32. Keycloak IDP • Based on WildFly server – Server Administration – Clustering • Supports custom look and feel (themes) • Supports custom authentication (providers) • Can authenticate users with external OpenID Connect or SAML 2.0 Identity Providers
- 33. Keycloak Relying Party (RP) • Keycloak calls them adapters • Out-of-the-box support includes – Spring Boot – Spring Security – Node.js – … http://www.keycloak.org/docs/3.2/securing_apps/t opics/oidc/java/java-adapters.html
- 34. Keycloak Brute Force Protection What is a brute force attack? “A brute-force attack is an attempt to discover a password by systematically trying every possible combination of letters, numbers, and symbols until you discover the one correct combination that works” https://www.owasp.org/index.php/Blocking_Brute _Force_Attacks
- 35. Keycloak Brute Force Protection • Preventing automated attacks: – Lock after 2 subsequent login failures – 1 second between failures (too quick for a human) – Lock remains active for ~5 min • Preventing manual attacks: – Lock after 30 subsequent login failures – Sliding window of 12 hours – Lock remains active for ~ 45 min https://ultimatesecurity.pro/post/brute-force/
- 36. Keycloak Password Policy What is a password policy? A Password Policy is the set of restrictions and/or requirements that a user must follow to ensure that their password is strong.
- 37. Keycloak Password Policy Keycloak policy types include: • Digits – minimum number of digits required • Special Characters - minimum number of special characters required • Expire Password – password expires after n days • … https://ultimatesecurity.pro/post/password-policy/
- 38. Keycloak Two-Factor Authentication What is Two-Factor Authentication? Two-factor authentication (also known as 2FA) is a method of confirming a user's claimed identity by utilizing a combination of two different factors: 1. Something they know 2. Something they have or something they are https://en.wikipedia.org/wiki/Two-step_verification
- 39. Keycloak Two-Factor Authentication • Keycloak authenticates users using: – Password – An one-time password (OTP) • A one-time password generated by Google Authenticator or FreeOTP https://ultimatesecurity.pro/post/2fa/
- 40. Keycloak as the Bridge • Bridge to external providers • Keycloak can authenticate users with – OpenID Connect 1.0 – SAML 2.0 – Social Identity Providers https://ultimatesecurity.pro/post/okta-saml/
- 41. Keycloak as the Bridge • Social Identity Providers – Google – Facebook – Twitter – Microsoft
- 42. Summary • Enforce a strong authentication scheme • Immediate support for advanced security features • Leverage future IDP enhancements
- 43. Thank you! • Contact me – www.linkedin.com/in/furmanmichael/ – ultimatesecpro@gmail.com – https://ultimatesecurity.pro/ – @ultimatesecpro
Notas do Editor
- Hi everyone, Thank you for joining the last lecture for today. What will we see today? I will start by giving you an overview of OpenID Connect. I will describe the OpenID Connect protocol, and will show you how it compares to other protocols. Then, we will review some of OpenID Connect Implementations. Finally, I will show you one of the best OpenID Connect implementations: Keycloak.
- Before we begin, a couple of words about me and the company I work for - Tufin. I have many years of experience in software development. Like most of you here today, I particularly like application security. I started to work in this area more than 10 years ago, and enjoy each day I work on it. For the last few years, I am responsible for the application security of all Tufin products. Something personal: I like traveling, reading books and listening to music. I particularly enjoy listen to jazz.
- And now, a couple of words about Tufin. Tufin is a great company. It is already over 13 years old (BAR MIZVA in this year). We have a lot of customers. Our customers are all around the world: in Israel, USA, Europe, Asia. Some are huge companies, others are much smaller. We have customers in many industries. For example: AT&T, BMW and Visa. Tufin is always growing. When I joined the company about 5 years ago, it took up only one and half floors. Now it takes up almost 4 floors and that is only in Israel. We have also expanded abroad. We recently opened up a new main office in Boston. CyberArk CEO has recommended to Tufin CEO Ruvi Kitov to open offices in Boston. We are always looking for good people. You can visit our site to see our open positions in RnD, Sales, Marketing and additional areas.
- Our customers are security experts and they expect a very high level of security. They have different types of requirements: Support various authentication schemas like Kerberos or SAML. Support advanced security features like password policy. About one year ago we were faced with a choice between two options: to develop these features in-house, or to adopt an existing implementation. I suggested that we adopt the OpenID Connect Protocol. Why OpenID Connect Protocol? By the end of this presentation, you will understand why! Who knows what is OpenID Connect? Who knows what is SAML? The OpenID Connect is the protocol based on OAuth 2.0. It uses REST/JSON messages. Design goal is “making simple things simple and complicated things possible”
- @Alex_A_Simons, Director of PM, Microsoft Identity Division, at European Identity & Cloud Conference 2018
- The protocol has adopted by many vendors. You can use OpenID Connect to implement authentication in your application using the big players in our industry: Google, Microsoft, PayPal and other public providers.
- The list of provider grows and you can always find new players, for example, Symantec https://www.symantec.com/connect/blogs/symantec-now-certified-openid-connect-provider
- Lets review OpenID Connect Components. The first entity is the IDP (stands for Identity Provider). IDP authenticates users. The second entity is the RP - Relying Party. Relying Party is your web site or application. For example, at Tufin, the Relying Party are any Tufin Products with web access.
- These are our components. RP, IDP and End user
- End user goes to a URL in a browser, in order to access a resource.
- RP redirects the request to IDP
- The IDP provides the login page. Please note that the login page is only the example if you are using Form Authentication. There are other authentication mechanisms that do not require the IDP to provide a login page. For example, with Kerberos authentication, a login page is not required and will not appear.
- But back to our example using Form Authentication The End User provides their credentials. (in this case, via the form displayed by the IDP)
- The IDP authenticates the End User.
- If the End User is successfully authenticated, the IDP redirects the request back to the RP. The token ID is passed as a URL parameter.
- RP can retrieve detailed End User information from the IDP via REST API. The user information is also called ID token. ID token is requested via the OAuth 2.0 protocol. Note: I am presenting an example of what is commonly called “Authorization code flow”. This flow is quite commonly used. It is intended for traditional web apps, as well as native or mobile apps. The channel from RP to IDP is called the “back end channel”. Implicit flow — for browser (JavaScript) based apps that don’t have a backend channel. In this case the ID token is received directly with the redirection response from the IDP. https://connect2id.com/learn/openid-connect
- Finally, the RP creates an authenticated session for the End User, based on the ID token, and provides the requested resource.
- Ok, SAML is well known and old protocol. SAML1 was introduced in 2002 and SAML2 in 2005. OpenID Connect is new protocol. Its final specifications were launched in February 2014. SAML uses XML messages, while OpenID Connect uses JSON/REST messages. Therefore, the total packet sizes used for the authentication dramatically decreased when you use OpenID Connect. One additional point: you can not use SAML for mobile or native applications.
- Does the flow look familiar? The SAML2 SP-Initiated SSO flow is similar to the Implicit flow of OpenID Connect.
- OpenID Connect is very similar to OpenID 2.0 Both are promoted by the OpenID Foundation (https://openid.net/foundation/) They even have very similar logos. OpenID 2.0 uses XML and a custom message signature scheme. OpenID Connect uses JSON Web Token (JWT) data structures, which you can user easily create interoperable applications.
- Last protocol we will compare to: OAuth 2.0. It is not an authentication protocol. OAuth 2.0 is designed solely to give application access to resources. You can open the provided link, and read a very good explanation of why it is not an authentication protocol. From https://en.wikipedia.org/wiki/Oauth OAuth is an authorization protocol, rather than an authentication protocol. Using OAuth on its own as an authentication method may be referred to as pseudo-authentication. On the other side, OAuth 2.0 is a great framework. You can use OAuth 2.0 flows and services and build the authentication protocol. So, if you put together Identity, Authentication, and OAuth 2.0 - you create OpenID Connect! Additional information. Not notes. https://developer.salesforce.com/page/Inside_OpenID_Connect_on_Force.com You might be asking yourself why we need OpenID Connect at all - after all, OAuth 2.0 provides an access token, which a client app can use to retrieve user information, effectively discovering the identity of the user to whom the token was issued. Why do we need an additional layer of protocol? The answer is that OAuth 2.0 allows the user to authorize the client app to access resources such as APIs on the user's behalf; the access token is a 'bearer' token allowing the app to make API calls. What happens if we do use the access token to represent the user's identity? Here is the problem with using those access tokens to represent authentication: OAuth 2.0 is designed to give apps access to resources; nothing more. Google+ Sign-In based on OpenID Connect.
- When you use OAuth 2.0 you will see the Authorization Prompt. An application request for permissions on your behalf.
- Ok, ladies and gentlemen, we completed the overview. Now that you understand it, your next question should then be: Michael, what is my next step? We want to adopt OpenID Connect in our organization - in our next sprint. Here is the answer: you need to select RP and then IDP. Who remember what is RP and what is IDP?
- The RP you ill depend on your specific application technology. If you have Python application you may select Python RP. If your application runs behind Apache HTTPd server, you will select this RP. Please open the provided link and select your Relying Party . Note that the list of RPs is always growing.
- You selected your RP, now you need to select your IDP. It can be one of Public IDPs I showed you in the beginning of the lecture. Additional option: you can select IDP from the same link.
- At Tufin, we selected Keycloak. It was selected for many reasons: It is an open source product. We required an OEM solution, and Keycloak met that requirement. It is continuously, and rapidly, being enhanced. RedHat supports Keycloak - and even its commercial product, RedHat SSO, is based on Keycloak (open the link) You definitely can select other IDPs – it depends on your requirements.
- Keycloak IDP is based on WildFly server. Many features configured in the same way as in WildFly server. (open the link http://localhost:8080/auth/) I do not have time to show all Keycloak options. Via Keycloak UI, you can manage users, roles. You can add OpenID Connect or SAML clients. Also, you can configure OpenID Connect or SAML 2.0 Identity Providers BTW, it supports various social identity providers as well, like Facebook, Twitter, or StackOveflow
- In addition to IDP Keycloak provides, out of the box, access to a long list of Relying Parties. If you select Keycloak, then you can select one of the provided Relying Parties (adapters). Ok, its is show time. I want to show you Single Sign On between two applications. I took the application from Spring Security Samples (spring-security-samples-tutorial-xml). Then I adopted the Keycloak Spring Security Adapter, using the instructions provided. (http://www.keycloak.org/docs/3.2/securing_apps/topics/oidc/java/spring-security-adapter.html) Then I used 2 instances of Tomcat servers. Each server uses different ports. I deployed the application into each tomcat. Note that each application has its own client ID and client secret. Now I can login to the first application. I will open the second application link and you will see that it also requires authentication. Ok, lets open two applications in the same session. Please note that I opened each application in a private window, so it has its own session. I open the first one, authenticate a user. Now I open the second application. Lets create one more user. Now the SSO case. Ladies and gentlemen, what do you think?
- Now I will describe couple of Keycloak Advanced Features. I guess everyone knows what “Brute Force Protection” is. I am happy to be able to provide you with the OWASP link in this presentation.
- Keycloak Brute Force Protection prevents both automated and manual attacks. You can change the settings provided in the slide via Keycloak UI. With your permissions I will change the Max Login Failures setting to 3 since I do not have time for 30 failed logins.
- A Password Policy is the set of restrictions or requirements for a password to be accepted. When an End User follows these restrictions and requirements, the password becomes a strong password. A Password Policy is one of the more common enterprise customers' requirements. Unfortunately, I was not able to find a formal definition of “Password Policy” on the OWASP site, so I wrote my own!
- Keycloak supports many policy types. For example, you can configure that the password includes minimum 2 digits or minimum 3 upper-case letters. (open link) Do you want to configure it? Lets do it. Let’s configure the policy. Now let’s add the new user, and enforce the requirement that the user must change their password after they first login. It is very simple, and very impressive.
- Please raise your if you know what is Two-Factor Authentication. Please keep it if you use Two-Factor Authentication day-to-day use. The second factor can be SMS or One Time password.
- Lets see the example of the SAML integration. I will show the example with OKTA commercial provider. Why I need to connect to my work computer?
- What we can learn from the lecture? If your business is not authentication, that your more than welcome to adopt OpenID connect. You can use strong authentication scheme, and you can support advanced security features.
- Thank you for participating in my lecture! Please contact me if you need any additional information, or if you want to send me your resume.