Mattias Lögdberg works as a Solution Architect and has specialized in Integration formerly on the Azure platform. Mattias loves to share his knowledge and experience, which has led him to speak in user groups and other conferences. He also runs the Integration User Group in Sweden (local events in Stockholm and Gothenburg). His love for inspiring others and sharing knowledge has been noticed, and in 2017 he got rewarded with Microsoft Azure MVP.
Identities have been with us for quite some time. If we go way back, the identities we were working with 10 years ago were more like service users that we created in our AD. Since then, everything has evolved quite a lot. Bringing in Azure AD, for instance, has brought us a lot of new things. It has developed from only user accounts to service accounts, then they introduced something called service principles, which is the next moment. Later we were able to programmatically create tokens with Azure AD, the client ID, and client secret. It was pretty good because it made it easier for us to give identity and access programmatically.
If we own the resources in our tenant, then we could use the Managed Identities. There are two types of identities, one called user assigned identity and one that is server-side. These two are giving us a way of granting access either to a specific resource or to user-managed identities.
But when we go outside of our enterprise or our tenant, and we get external parties who want to use our Connector API management, for instance, then we can give them a service principle. Also, when you do something that you’re going to run on-premise that is not a cloud service, you can use these service principles to access the service you’re creating.
Mattias Lögdberg is presenting a session on day 3 (15th June) of INTEGRATE 2022. He will speak about “Long lasting build and release for Integration. ” Look what Mattias says about his session,
“As integration developers, we build more services than any other team; we also want to have as little maintenance as possible. This could mean it takes years before we come back and revisit something we built. At that time, we want to have that deep understanding and confidence to make the change swiftly without spending a lot of investigation.
One of these parts helping us get a quick view of what we need to do is the Build and Release process; if it is a good one, we can be confident in our work, and if it is a mix of releases and manual tasks, it can be a pain. In this session, let’s investigate the critical components in a significant release setup”.
Mattias LinkedIn profile: Click Here