Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Identity management and single sign on - how much flexibility
Similar to Identity management and single sign on - how much flexibility (20)
More from Ryan Dawson
More from Ryan Dawson (14)
Recently uploaded
Recently uploaded (20)
Identity management and single sign on - how much flexibility
- 1. Identity Management and Single Sign-on - How Much Flexibility? Experiences with Keycloak Ryan Dawson @ryandawsongb Marcello Teodori @magomarcelo Alfresco London Microservices 14/11/18
- 2. What we’ll talk about -Auth and identity background -Where Keycloak sits -Examples of what we do in our projects -Tradeoffs we make -Why we made the decisions we did with Keycloak -Other key challenges
- 3. Our Starting Problem(s) We provide an open source product and an enterprise one on top of it Both used in lots of ways Lots of auth scenarios Lots of protocols Wanted consistent approach
- 5. Or this?
- 6. Meaning... ...everyone doing things their own way so interoperability becomes tricky
- 7. Now We Have OAuth
- 8. And OpenID Connect (OIDC) And OIDC Helps to Nail this down further by building on OAuth and formalising the content of the ID token as JWT that asserts identity, coming from an issuing authority, with a particular audience (client) and expiration and signature…
- 9. Of Course We’re Simplifying -The details of OAuth and OIDC do get complex -Especially when you get into the different flows and scopes -For us we’d still need to support a range of protocols -Also there is more to be solved - we need to break the problems down more
- 10. Auth and IDM are not the same - Authentication = am I who I claim to be? - Authorisation = can I access this? - Identity management = who am I and what is stored about me?
- 11. Auth and IDM from a dev perspective Login code will normally be doing authentication and authorisation. It just needs to know my ID and permission. Capturing my name and address might would under IDM. More subtly, my LDAP groups might be IDM. Could be department I’m in. But you could also create roles that mirror LDAP groups in some situations. Auth and IDM are different concerns but they can be related. You might apply a role to all users in a group.
- 12. It’s a Complex Landscape OAUTH2
- 13. And Still Kinda Boring -Even with OAuth, Auth code still not fun -Auth server implementation not fun -Maintenance definitely not fun
- 14. But could it become cool?
- 15. A Keycloak Journey: monolithic architecture
- 16. A Keycloak Journey: microservices architecture
- 17. A Keycloak Journey: authentication
- 18. A Keycloak Journey: microservices with Keycloak
- 19. Commoditization of Auth and IDM Protocols offer standardisation. But Keycloak is a move towards commoditization. It handles federated identity as well as SSO And it aims to provide OOTB ways of using it. Auth0 and Okta have a similar range of features but they are SaaS. Other products that can work on-premises like CloudFoundry UAA are less rich in features for our needs.
- 20. Commoditization = somebody did it for you
- 21. So Why Keycloak? - Not to be cool. Or because others are using it. - To make it easy. - To let experts manage that code. - I don’t want or need to implement an auth server. Or to write different code for different protocols. I’ll just use keycloak adapter code in my microservices. - I don’t want to write code to manage users or interact directly with LDAP. - If it all works out well, I can just google for ‘keycloak spring boot’ and get something working with copy-paste. Or ‘keycloak angular’ or whatever I’m using.
- 22. Cool =
- 23. All this for free? -There are other tools out there that aim to help in this field. There are tradeoffs all over the place. -First let’s look at some concrete examples, so that we can appreciate the tradeoffs better.
- 24. Let’s See
- 25. Here’s a Cool UI
- 26. The Code is Cool Too https://github.com/Activiti/activiti-modeling-app https://github.com/Alfresco/alfresco-js-api#authentication-js-api "oauth2": { "host": "http://activiti-keycloak.activiti.envalfresco.com/auth/realms/activiti", "authPath": "/protocol/openid-connect/token/", "clientId": "activiti", "scope": "openid", "implicitFlow": true, "silentLogin": true, "redirectSilentIframeUri": "/activiti-cloud-modeling/assets/silent-refresh.html", "redirectUri": "/activiti-cloud-modeling", "redirectUriLogout": "/activiti-cloud-modeling" }
- 28. A Cool Backend Behind It
- 30. A Configured Realm There’s shared configuration across all apps that use this realm. It contains details of which ‘clients’ (apps or app profiles) should be authorized for logins under the realm as well as user roles and user details (or the source of user details)
- 31. SSO in action
- 32. Here’s another Cool UI with SSO! https://github.com/Alfresco/alfresco-content-app
- 33. Tradeoffs and Decisions -There are some tricky decisions and tradeoffs involved in designing implementations using keycloak -Let’s look at the key ones and see the flavour of the various challenges
- 34. Key Tradeoff 1 - Just OAuth2? Or just keycloak? -In both UI and backend cases - do you use the keycloak adapter and get support for other protocols? Or are you just doing OAuth2? -If you’re just doing OAuth, then implementing your code in a generic OAuth way with an OAuth library would let you swap in another auth system e.g. UAA.
- 35. Key Tradeoff 2 - How Much Coding? - In the backend we could’ve gone for plain spring security. This is a configuration over coding approach. But can still be pretty involved - the configuration is still there in your code. -The keycloak adapters make it a bit more out of the box
- 36. Our choice - Will you really be doing all these different protocols? Important for us because we’re a vendor… our customers will! - JHipster went the other way - they decided supporting multiple OAuth2 SSO implementations (e.g. UAA) without having to switch adapters was more important for them. -The variety of use-cases was key for us, especially: -Social login -Kerberos and SAML -Brokering Options in General, especially the range -LDAP Support -LDAP sync also a big plus.
- 37. So Is Keycloak Cool? -For us it lets us provide super-flexible security out of the box. -That delivers value, so that’s pretty cool. -And it lets us do it in a way that the software community can recognise and work with.
- 38. Thanks for Listening! Please do ask questions! (Or we can talk about additional challenges if we have time.) And by the way, if you want to work with Keycloak and other cool technologies… We’re hiring in our team! Check https://careers.smartrecruiters.com/Alfresco Contact Us: Ryan Dawson @ryandawsongb and Marcello Teodori @magomarcelo
- 39. There are Challenges Making these decisions solves some problems But still leaves a lot of work to be done Let’s see some of the challenges you have to address
- 40. CORS CORS - keycloak libraries can kinda help with this but only a bit. Partly because putting keycloak on the same host is tricky. It really wants to be on the root path. But everyone wants that, don’t they? Gateways love root path. UIs love it… So does keycloak.
- 41. SSL
- 42. Data Restrictions Access restrictions on data, not just endpoints. You can add restrictions at code-level with spring But in our case we wanted the restrictions to be configurable at deploy time and to be able to apply them or not apply them with configuration options, including to dynamic queries not just static ones. We also needed the restrictions to be able to apply for a chosen group or user rather than a role. So we wrote something. https://github.com/Activiti/activiti-cloud-query- service/blob/b6ff8c630fb4d171188b4262bd4bccffd8ee10e4/activiti-cloud-services- query/activiti-cloud-services-query-
- 43. What if Not All User Info is in Keycloak? What if you’ve got extra attributes about users that are not stored in keycloak? Ideally that could be handled via federated identity brokering Otherwise you’ll need to take some identifier and use it in both keycloak and your app’s database/persistence Probably then you’ll also be querying the REST api to find out about users and groups from within your app. If so using the OOTB java adapter library makes a lot of sense as it wraps the REST API.
- 44. Upgrades Upgrading keycloak itself tends to be fairly smooth as minor versions are backward- compatible and major ones will have migration path. But realm changes can be a pain. The realm import/export feature can help with some limitations. { "realm": "activiti", "enabled": true, "sslRequired" : "none", "roles": { "realm": [{ "name": "ACTIVITI_USER" }, { "name": "ACTIVITI_ADMIN" },] "groups": [{ "name": "hr" }], "users": [{ "username": "admin", "enabled": true, "credentials": [{ "type": "password", "value": "admin" }, "realmRoles": [ "ACTIVITI_ADMIN" ] }] }
Editor's Notes
- Ryan: I’m Ryan Dawson, one of the core developers on the Activiti project. We do open source Business Process Management and Automation. Marcello: I’m Marcello Teodori, Architect for the Alfresco Process Services enterprise BPM product. Ryan: We both work on Business Process Management but we’re not going to talk about that. We’re going to talk about single sign-on and identity management. We’ve changed the approach to authentication and IDM in Activiti and Alfresco products recently as we’ve increasingly moved to cloud-based and distributed systems. Marcello: So we’ve been breaking down monoliths and refactoring out responsibilities. We looked at the market to see what we could leverage and we’d like to share what we decided upon. Comments and other experiences are welcome - do feel free to ask questions as we go.
- Ryan: Rather than dive straight into our decision-making, we’ll start with some background. We did end up choosing redhat’s open source offering keycloak, at least as our first/primary auth and IDM integration. We’ll explain why. Marcello: We’ll show you what we’ve done with keycloak by demoing just the relevant parts of some of our open source apps and digging into the code. We’ll also explain what trade-offs we encountered and challenges we faced.
- Ryan: Let’s briefly summarise the position we started from when we were reviewing our auth setup. Our products get used in lots of ways, both open source and enterprise. This means lots of auth scenarios. So we’re talking cases with our backends talking to 3rd-party frontends and our frontends talking to 3rd-party backends and backends talking to backends. Also cases where authentication is with basic auth or OAuth or SAML or kerberos. And parts of the user record could be internal to the system (in the DB) or in LDAP or somewhere else. Marcello: Sometimes we provide the integration code and we know all about it. Sometimes users extend our products themselves. We wanted to unify this and make it more manageable. We wanted a set of services in a distributed system - consistency. And that meant externalizing auth where it was done internal to service. But we couldn’t lose functionality. Ryan: to understand this better let’s break the problems down and get a picture of how they evolved.
- Ryan: You might well be thinking that the problems we described with systems having their own approaches to authentication are unusual. But If you’re old enough you probably wrote something like this. You wrote all the pages and all the code behind the pages and dealt with all the pain of controlling access to specific resources. It wasn’t unusual to write login and access control code.
- Ryan: You also modeled all the users in the system. That meant storing passwords and securing within your application.
- Ryan: This isn’t to say we were all neglectful back then. But in a sense we were cowboys. Without established practices everyone is a cowboy. One of the big problems we were looking at was systems storing user and password details in the database and requiring them for access. Encrypted passwords but the key problem is interoperability (how can a user do an action spanning systems without multiple login?) and consistency (what if the same user has slightly different names in different systems?) rather than security.
- Ryan: OAuth means there are standard ways for different types of applications to do authentication and authorisation. And they don’t all have to store their own user-password records as they can use an OAuth server. The application can pass requests on to an OAuth Authorization server and that can issue a time-limited access token that grants access to specific resources.
- Marcello: And OpenID Connect adds to OAuth, making it more specific. A big addition is a formal specification for an access token as a JWT (Json Web Token). The basic principle is that a token should come from a recognised issuing authority and be signed by that authority and the client should be able to verify this. The token should contain everything needed to know who the token is for and what it entitles them to be able to do.
- Ryan: There’s much more to OAuth and OIDC than we can fully go into - choosing to use them does help us out but doesn’t solve all of our problems. One reason for this is that we’d still need a way to support a range of protocols. But more importantly OIDC alone doesn’t address all of our core problems. To understand why, we need to break the problems down more.
- Ryan: First we we need to break down what problems we’re trying to solve. That means being clear that authentication and identity management are not the same. For a user, you’re getting authenticated when you login. You might also get authorised at login. Probably authorisation happens every time you move from one function to another. You engage with IDM when you modify your user details - think of going to a ‘my account’ page. Different functions from a user perspective and they could be implemented by different systems or parts of systems.
- Ryan: So let’s think from a dev perspective. Can we think of examples of functions implementing parts of these concerns? Login code is an obvious one. Authentication will take place when login happens. Authorisation will happen right after that to decide if the user can go where they want to go. Login needs to know my ID and maybe my password or whatever entitles me to access. Authorisation needs to know that I’m entitled but it doesn’t need to verify my identity again. Functions that involve updating or using my name and address will be IDM-related. That is part of my identity but probably not relevant to authentication. These distinctions can get tricky. For example, what if I’m a member of a group in LDAP? Say I’m in the finance department. Is that an IDM concern or an authorisation concern? The way to think of it is that groups are a way of organising users/people but roles are ways of organising rights/entitlements. My being in the finance department means I’m in a group. It might be used to grant me certain roles too as finance can have certain privileges (access to accounts). The point is that OAuth is a standard for authorization and OIDC adds to it and helps it cover authorization. Identity management including managing changes to groups and extended user details can still be a problem and it can relate to auth.
- Marcello: There are other standards flying around. Some might be called legacy but they are still around and sometimes it is very hard for organisations to migrate. Even if you could ignore legacy, there are still other protocols and tools in the auth and IDM area that are too important to comfortably ignore.
- Ryan: The point is even if we were to just choose OIDC/Oauth, implementing everything according that standard would be a lot of work without off the shelf tools. Especially if it is going to incorporate user and group management and integration with roles. Then there’s all the maintenance of patching security code when new updates to a protocol come out in response to vulnerabilities. So we wanted to be able to use an off the shelf system as far as we could.
- Ryan: The one that stood out was Keycloak. It’s an open source project from redhat. It is getting pretty popular and showing up at the cool conferences. It has the potential to address auth and IDM concerns and provide ways to handle various protocols and legacy stuff. You set up a keycloak server and that becomes your single point of interface for your apps. That would be kinda cool.
- Marcello: the Alfresco Content and Process enterprise applications did fall into this category, handling user credentials and profile storage, role and group mappings for authorisation, then LDAP sync, then SSO, all implemented in Java with Spring, a lot of Spring…. and duplicating effort
- Marcello: sharing user database or calling a custom login service and a user profile service or inventing their own tokens and ways
- Marcello: enter keycloak, centralised login and standard protocols, LDAP sync, SSO all in one place
- Marcello: every service just relies on the token provided has the mean to validate, stateless!
- Marcello: Keycloak doesn’t just provide an OAuth2 server. It can handle other protocols too. And it can do identity management. It’s not alone in this but it seems to be the most popular.
- Ryan: The keycloak documentation doesn’t say Commoditization. But they do talk about range of use-cases, including using keycloak as a single point of interaction and putting it in front of other providers (e.g. even using OKTA as IDP behind keycloak). And they talk about their adapters as reducing boilerplate relative to libraries. Their demos tend to use the adapters to show things as ‘OOTB’.
- Ryan: Following the crowd can be good if it means that knowledge of the tool you choose is widespread - then it’s easier to developers and to find answers online. But popularity isn’t a reason in itself. We do want to let somebody else do the hard work for us. Again, not always a good reason but sometimes it can be. The less time we spend on auth and idm, the more we spend on our core business. We recognise it’s not our core expertise and are happy letting experts do it. And this is important because we have been doing this before. And there are still options around that will lead to you implementing your own auth server or writing code that handles different protocols. I don’t want to write auth code or idm code or code to interact with common idm systems unless I have to. The keycloak adapters have the promise of doing a lot for me.
- Ryan: Actually one better than copy-pasting would be not even having to copy-paste. That would be true commoditization. The point is you want to just add the library and do some configuration and be up and running.
- Ryan: It is open source and that was important for us when we were evaluating it. We wanted to externalise auth and idm from Activiti as Activiti moves to microservices (because microservices means separating out responsibilities). And Activiti is open source so we needed something open source. The range of use-cases was also important because we also use Activiti and build on it in enterprise products and enterprises have lots of use-cases, including lots of legacy stuff. So the promise is big. But does it really just work?
- Ryan: So how much does keycloak do for us? We need to look at some real applications to find out. We’ll show: end user login experience in your front-end app back-end API behind it Identity Service with its web ui
- Ryan: This is one of our angular UI apps. We hit the app URL, we get redirected to keycloak and after login we get into our app under our identity and we see the stuff we are meant to see - the stuff that belongs to us. Marcello: This flow is the implicit flow of OpenID Connect and allows the integration of SSO via external providers or 2FA as your application DOES not manage the login screen or is in charge of sending a username/password pair.
- Marcello: This is cool because it’s basically all config, very little code. But that’s just because logic is handled a library layer (Alfresco JS API) so actually there is oauth2 code but we’ve hidden it. In this case it is generic oauth2 code. We’ve a different UI that is using keycloak-angular and integrating that was fairly straightforward. This is a key choice between oauth2 code or a keycloak adapter.
- Marcello: It’s important this config is externalizable as this is one UI of several that need to work with lots of backends in kubernetes and be deployed to different clusters. We need to be able to pass in the external URL and config as environment variables so we can set at deploy time.
- Ryan: so the UI passes the token through to the backend, which also uses it: http://activiti-cloud-gateway.activiti.envalfresco.com/activiti-cloud-modeling-backend/swagger-ui.html#/applications
- Ryan: Here we’re using a keycloak adapter in our library code. Otherwise pretty similar to keycloak spring boot demos. Again it’s all externalised because spring boot properties map to environment variables. Notice the constraints section especially. This lets you restrict which user roles can access which endpoints. These restrictions are all at the config level out of the box with the keycloak adapter, whereas with spring security it is in the SecurityConfig class and you’d then have to externalise it yourself.
- Ryan: The configuration of users and roles and which apps are allowed to do what is all in keycloak. So outside of your apps. And again deployed in kubernetes - the helm chart has helped us a lot here. Obviously there’s a lot of detail in the realm config. There’s a lot to learn when it comes to configuring keycloak for different scenarios. However, we’ve found it pretty easy to get something up quickly by following examples.
- We’ve got multiple UIs and multiple backends and a single user can move seamlessly across them. So it really does work. Marcello: add a slide for alfresco-content-app and show SSO
- Marcello: SSO in Action, alfresco-content-app is the Angular front-end for Alfresco Content (both Community OSS and Enterprise) and they are configured to login on the same keycloak server, so we can switch seamlessly from on to the other with the same user identity.
- Ryan:
- Ryan: If you go with an Oauth library then you can support other Oauth servers. If you go for a keycloak library, you can support other protocols and scenarios. But with one library you can’t have both. We hit this with both backend and frontend. We used the keycloak adapter for the backend but we intend to add backend support for UAA as an alternative to keycloak for authentication. We use the keycloak adapter but we do so at a library level in our code, not to hide it but because we need the implementation to be pluggable so that apps built on Activiti can override and extend it. Currently the UI has gone the Oauth route but there is a keycloak angular adapter out there.
- Marcello: For us actually the key code-level challenges were integrating keycloak smoothly so that the configuration was all neatly externalised (actually this was quite easy with the adapter) and also making sure it could be swapped out or overridden. But many projects might choose to go plain spring security for Oauth and configure it for keycloak as the Oauth server. JHipster went that way. It avoids having to implement the Oauth server yourself but the code-level configuration is a bit more involved if you go that way.
- Marcello: focusing on enterprise solutions
- Ryan: Keycloak having a good open source community is really important for us. It means we can dig into the code and contribute and collaborate. The range of features and flexibility of keycloak is also key as it lets us cover a really wide range of cases, including the kinds of cases you hit in enterprise organisations. It lets us deliver value for our community and customers so that’s pretty cool.
- Marcello
- Ryan
- Ryan: Not strictly an IDM or SSO concern but if you’re doing SSO then you’ll probably hit it.
- Ryan: Again not an SSO or IDM concern but if you’re doing SSO then you’ll probably hit it. Keycloak does let you configure whether SSL is required for logging in to a given realm.
- Ryan
- Marcello
- Marcello: Clients with older versions of the adapters will tend to work when you upgrade the server, at least with minor versions. You do need to do testing on upgrades though. Changes you make to the configuration can be trickier than you might expect as not everything is currently exportable from the UI.