>> Okay folks. Good morning My name is Jose Rojas I’m very happy to be with you today I’m a program manager within the Azure AD B2C team We are a team for over two years working very closely with some awesome engineers on developing the Identity Express Framework, which otherwise our B2C service I’ll make the distinction clear to guys today This is a technical track and though it’s mostly lecture today, it’s just a necessary foundation for this subsequent discussion we’re going to have because we’re going to get technical very quickly, and that’s what we’re here for So let’s do it. I think I already made the introduction We just want to make sure you guys feel comfortable with the basic flows of Identity Experience Framework because these are building blocks, right? This is by how you use Lego blocks What you create with the Lego blocks is going to be up to you. And a quick audience check Really, the main reason is to, so we can leverage with each other in terms of where we are, in terms of our learning How many of you have already used B2C with a customer? Fantastic. How many of you have gone to the XML and actually configured an XML? Raise of hands Great. Great. And then, similar question, but now for the prework itself: how many of you guys were able to complete the prework, for this session? Getting started with custom policies That’s really good Kudos to you guys I think you’ve heard from our colleagues We’re going to have a few catch-up sessions One of our biggest goals of your visit today, just today is that you walk away being able to run through this, so you can build and be a trainer to your own your family, so to speak Your own workmates, back where you came from So we want to make sure that happens, okay? That happens this afternoon in the additional session Tomorrow, 7:30, we’ll do another session to catch up anybody And it fits like catch up and if you have more complicated questions to ask, come on over, okay? We are privileged to have the engineers who actually have coded this and designed it with us today and tomorrow Please take advantage of it Awesome So, what we’re going to cover through is core concepts and building blocks We’re going to go through a trust framework policy, how it’s designed We have one of the authors of the language itself with us presenting And then we’re just going to go right to that starter pack to make sure you understand what it is that you did last night, when you completely get started On the Identity Experience Framework is a new technology at Microsoft Relatively new technology build Really, the team kind of got together over three years ago And it is a new way to provide composable identity across any entity, ultimately with any protocol It’s almost infinitely configurable And it’s a huge distinction on Microsoft Identity platform because it does the identity work for your applications As opposed to your applications doing to, you have to identity work with their bunch of APIs Our biggest, one of our biggest value ads, is that you program the platform It’s your platform, your version of that platform, to provide the services to any number of apps And those apps have to do a minimum amount of work It makes sense from a development perspective, control perspective, and from a perspective of control Sorry, security is the last thing I want to say Control, flexibility, and security So, what does this slide show? And I think my colleague talked about that earlier, so I’m glad that Parak talked about it We have a platform that our team provides and stands up And on top of that platform, we deliver to service called B2C And we’re very proud of what it can do and will continue to do But what IEF can do is, goes beyond B2C use cases And in some of these examples, we had our colleagues at Microsoft consulting develop a platform on top of it, that they sell us a sports platform And we see you guys in the far left You already Identity pros You have ideas. You have products. You have concepts You have solutions that you know you’re niches need, by vertical, by country, by regulatory body that you’re going to provide We hope you choose us as your platform but it’s your IP that goes on top and you run it But it also means that you have additional responsibilities to make that happen with learning how to configure it and working with us We really hope you take us up on that because when you do, you have, through the framework, access to Microsoft services on the left And you can see the list As well as, any number of services on the right, and you can interface with common standards That’s the concept behind it The Identity Experience Framework, is an orchestration Orchestration and you know it’s at the core Hopefully, it’s coming up is a number that you have seen this slide before, but let me walk through it very quickly We have a user accessing through a device And through that device, it’s accessing an application That’s pretty standard That application is a reliant party in an Open ID connect connection And that application reaches into the framework

And it says, “Hey you, this is me I want to invoke this policy.” That policy then says, “I want to do this policy through this endpoint.” The endpoint, it takes what? What protocol? But beyond that, what the ensuing conversation that happens, it’s based entirely on that policy So your tenant can, in the same tenant, talk to multiple protocols, multiple applications, and solve additional problems, depending what you configure in the policy Because then the orchestration engine can go in sequence through any one of these objects at the bottom And this is just an example And what we call out is that even the built-in parts of B2C or IEF, are things you can access as if they were external to the platform That is your own directory It’s something you reach out to and you do things with, right? The Azure MFA is something you reach out to and do things with The beauty of this way to configure is that if you one day choose to use a different Azure MFA Sorry, a different MFA service, different to it’s face service, you can do that You can go as far as using a user directory somewhere else You might decide that a customer’s DV Now I’m pushing the boundaries, but you might decide that a different kind of database is the right database for your solution You could do it with our framework I’m providing these as examples I’m not encouraging you to go do that, but I want you to understand the modularity that’s underneath it to create and complete your cases I have a little box here, square box called Rest API, which basically comes everything is in the world that can speak to us via put in gets, right? And that ability’s there So you can figure the middle Obviously, you have a responsibility for the testing, for the monitoring, and we’re going to continue the engine running for you So let’s talk about how this happens The orchestration engine that you get to program has a number of different pieces and parts to it I won’t go in much detail to it today, but I just want you to be aware and look through different components From the upper left, the request orchestration, which comes in The ability transform claims, so that different entities can talk to each other because the type of the data might be different, because what they call it might be different, because the order of things or the collections versus strings are different Those things can be transformed So the systems can talk to each other The orchestrator has to translate between them And we have numb voice to do that In the lower left, the message processing then, that’s where the endpoints are very protocol related And we have a number of protocols we built in and over time, we’ll release more protocols And they all get to the leverage pretty much the same way And on the bottom right, the claims validation service talks about them, about the security The security, whether this is protocol compliant or whether this sender is allowed to be talking to us at a given point in time, and then come up with the tokens that go back to your application This is what you get to code, is what you get to configure So let’s go in to talk to a little bit about the policies themselves and let’s get theoretical just for a minute The trust framework itself in intangible form is an XML file But in reality really, it’s kind of a contract It’s kind of a contract that dictates how different parties can talk to each other, what information they can share, what do they each call things In one platform is called a name and one platform is called first name, one platform is called telephone, and another platform is called something else That legend, or how each party talks, and who can talk to who, using what protocol and do what, is embodied in trust framework Typically a central body controls this file The set of files is configuration and manages the trust across different parties, right? Even the calling of which keys are the enforcer, the cryptography between different parties, it’s configured in the policy That keys are somewhere else But actually, what key is invoked in what transaction is invoked in the policy So that’s what the policy is for you and that trust So theoretically speaking, defines rules that governs the information exchange as I talked about In the example, one’s blue, one’s green But they’re talking to each other in different languages, but the platform gets to translate between them And lastly, becomes an auditable document that your customers can review, approve, and unless changes are being done, it’s blessed. It’s good Don’t touch it until the next reveal, the next time we need to go back to it Some organizations are really sensitive about that and very well they should be One thing that I find really interesting too is that, when the relationships get established in a trust framework, you often do not know, you might not know who are the ultimate governing body is going to be You know how many participants are going to be Like especially in government situations, you don’t need to start knowing exactly how many people are going to participate or what are their ultimate rules You can just get started. And that’s what happened in, specifically in Ireland And one entity decided to start working with us

And that entity said, “Hey, I have a good idea Why don’t we create a new identity provider for the government of Ireland?” So instead of you solving their problems in that one agency, they just kind of looked up and said, “Let’s do something wider.” Your customers could do that You could very well start with one customer, one part of the corporation, or one part of the government, and over time, as they see that this works well, the same policies can be adjusted and grow with the situation, as opposed to having to rebuild things from scratch And that’s an interesting, interesting concept, especially in government where making major decisions suffers many organizations is honestly kind of impossible right? You’ve got to get started somewhere and it works We wanted to clarify that our policies, the policies that we’re talking about today, are the same policies that are used in our B2C Built-In Policies engine, right Underneath the hood, they’re the same policies We want to help you quickly think through, one unit, one versus the other First, a target users are very important, I think you get it You guys are the identity pros You guys are the ones that we want to encourage to use the identity experience framework, whereas for most developers, we really want to point them to the kind of get in/get out type of service that B2C represents Configuration, over time we expect to be continued to improve the way you configure the items on the right, but today, it is straight up XML editing But a number of things are the same, right So UI customization, we have no difference The ability to do attribute customization, token and session management It is not our purpose to have any differentiation between the two We hope that you can do both with either versions of the service So, those are not reasons to move to the right And lastly, identity providers, over time we will also allow one on the left to use any identity provider.That’s part of our plan Today, there’s a fixed set of identity providers we kind of blast than configured But the one on the right, I’ll ask you to use any protocol that we support from openly connect OAUTH and SAML today, and we have a couple f commune like wSfed that are in the platform where we haven’t yet thoroughly tested In terms of sub quick ideas or some of the scenarios we’ve seen people build, we’ve built ourselves and with some folks in AH Take a quick look at the right side The idea is within B2C situations, within a customer facing situations, and really in this case, consumers for the most part These are some of the things that some folks have built up Some on our team, some folks sitting in this audience, some of you guys have built, that they’ve taken this journey engine right to six, this is a identity screen framework then created, right So anything from sign up while sending a welcome e-mail from the platform, using a third party provider, 2FA with in a standard interesting compliant validator, such as authie, for example, or Microsoft authenticator, log in with one button, linking of account So, one user two accounts Has local accounts has a Facebook account or has a corporate account And one, at least two of those that they can be linked to the same user So a number of really interesting use cases that are enabled by that. And you see the rest So the idea is kind of why am I even here Well, it’s because far more is possible And we really look at you guys honestly, to help us innovate Because that demands, the things that your customers need. Number one, you know better Number two, there’s so much to be done, that we hope we can engage you guys to build the future with us And you tell us what’s missing in terms of things Lego blocks that you need, and we’ll work on that blocks so that you can provide and build that castle that you want to build, right So you build that We see more and more how you can build your own solutions while we provide you the infrastructure to do it And so far I’ve seen some great innovation for users. Thank you Hopefully, you’re familiar with this interface we came up with recently We will improve it over time We have lots of ideas of how to make this a lot more usable At this point, we can have really a shell of managing direct single files But want to make sure that you guys are aware I’m particular part of the work done on policy keys, just in terms of making something extremely sick to my mind scary and complicated so easy And we have one of the authors of that work here as well running But this is the interface we provide and we hope that you can give us feedback, both in terms of organizing and when you have many many different policies And also in terms of how we actually build them over time Because we notice it becomes a direct exercise If you think by now, judging by that many of you who are already kind of dove in Hopefully, much of this doesn’t become redundant But by now, I think we get, right that a policy, is what they takes to configure configuration, both to communicate across different entities And also, that today as you’ve seen it yourself, it’s a XML-based Important at the bottom, the [inaudible] mashable flows I think that together with or little bit delay we’ll talk about dependencies, how they work

Cause there are some creative things that are possible there When I talk about control, who controls access to which files? Who controls access to which portions of the configuration? So you can have developers creating some policies and identity pros or yourself perhaps, madden upper level policies and in a chain It is something that we’ll discuss a little bit, because it does mean that you have the ability to trust a few things to others and keeps some things to yourselves So we’ve seen the types of policies and by now, I think this audience pretty familiar with the fact that our applications dictate which policy should be used, which gives flexibility to an application, to call many different policies It also allows more than one application to call the same policy that’s appropriate and the variations can be simple things like branding, the variations could be like you know one application registration is linked here And the other, one could be that one application less trusted So they don’t get a token that as rich as the other applications So that this is something that’s determined on the policy that each one gets to access So this is a flexibility that opens up a lot of different scenarios And lastly, just the session enforcement that we’ll talk more about in some sessions today as well, but I think you’re aware that you can name four sessions had the SSO, the policy ten in an application level So what are these elements and how are we getting down into the code itself? And I should say the configuration file So we have within the XML, we have five sections and I’m just going to introduce the top and I’ll hand it over to Homer So what we have is, number one, that the base policy Base policy really determines who is the parent of this particular file? Allowing that they are co-existent to multiple reliant party files to call one based trust framework So you write, the base trust framework or the core file once, and you have the ability to make multiple copies or multiple variations on a policy without changing the heart or the core of it Building blocks, I think we’ll go in a bit It describes the relationships Claims providers are the entities that you interact with Everything including the human you’re interacting to, is mapped or modeled as an entity, that happens to be a claims provider or self-assertive provider The user journeys are the step-by-steps it themselves, to achieve what you want to achieve And all the way to the right is how do you going to speak back to the application? What is the application the relying party is expecting So I’d like to introduce Omer [inaudible] sorry had a question before we do more You bet. So this is a schema And thank you for that And I will, Omer will show you in the XML file Think of this as the schema of our XML configuration file The file has, five elements Five macroblocks, if you will Of in the schema, and the contents of each block are described here So the first block, has one element The second, I believe has five and so on so forth, right So this is just to give you the schema and how it is organized in the configuration, that’s what it is So Omer, together with a couple of engineers was the author of this language, to start with So we’re really, happy glad to have him with us >> Thank you very much Mike Thank you very much. Mr. Jose If we just validate that this works or doesn’t work, it works. All right So basically, what he said, I’ll build on that The way we have architected identity experience framework is that you can author your own trust framework A policy that provides basic set of rules, and journey’s, and user experiences for other policies, your application policies to work on it When we started the B2C project, we did the the framework before we actually came up with the B2C offering So it is not a retrofit of going back and then trying to build a framework underneath the B2C offering, it was actually the other way around We started with the framework and then, one of the concrete examples of whether we can utilize that framework in real world or not, was to build the B2C on top of it So, this slide represents a very high level of what base policy, building blocks, claims providers, user journeys, and relying party sections are Today and over the next few sessions tomorrow, we will actually go into each one of them I’m going to cover some basics around What the policies and how inheritance works? And a few sections, but then tomorrow’s session, I think there is two or three sessions

tomorrow when we actually going to, what claims transformations are, what content definitions are, and the radius of the policy >> This is appeasement, right? Yeah, okay. So, policy inheritance is a core concept of Identity Experience Framework Usually, nobody has one policy that is a standalone Typically, that’s not the case It’s possible you can author one huge policy, which will have everything from the user experience to how the token is maintained, which protocol is used, what relying party uses, how you are going to federate with another identity provider All of that is possible to put in one policy But typically the way we have seen it work effectively in practice, is that it helps to isolate each one of them So due to that, very early on, we built inheritance into the system When I say inheritance, I mean similar to what we’re used to inheritance in programming languages We can typically have one based trust framework where we can say, “These are all my user journeys, these are my identity providers that I’m going to federate with These are the protocols they use.” And then every application can go and overwrite some of those behaviors depending on its needs For example, one application might want to get some extra claims from a particular identity provider or an application might need to get additional claims in the token And it can then start modifying that base user journey, Base Trust Framework policy It can also modify the base user journeys to achieve some experience for the user That’s at a high-level, I’ll go through the XML snippets for each one of those Once we had this platform, the example I was talking about if you were to start with custom policies and download your policies, you will typically find three or four different policies There will be a base policy, there will be an extensions policy, and there will be some application policies If you’re new to it, just bear with me, I’ll show all of these through the examples That model that we have put in the starter packs, when you start with custom policies, is based on our personal experience of building the B2C Trust Framework So if you have a tenant where you go and try B2C, set up a policy through the UI There was an earlier session by Parik, where he showed how you can go and create a new policy, where you can say it’s a sign up policy and I want these claims and I want them token Once you download that policy, you can open the XML snippet and see that it talks about a base policy and that base policy, so this is the policy that you will, I don’t think the mouse shows up, so I’ll just walk over and talk about it This B2C one policy is the policy that you are modifying on the portal And if you download this policy, it will have a reference to a Base-V1 policy within your own tenant So in the portal, you will see there are two set of settings that you have One is the settings that you’re doing at the tenant level and another set of settings that is per policy And this is how we have broken it up in the policy inheritance So there’s a tenant-level setting where you can go and say, “I’m going to configure Google as an IDP I’m going to configure Facebook as an IDP.” And that’s a setting that all my policies can use And then each individual sign up, sign in, password reset, whatever setting you have can start using those IDPs from the Base-V1 policy So you end up providing your client credentials and your client ID, app ID one time that we go and put in the Base-V1, the portal will do it behind the scenes And then every policy is inheriting that data and then able to federate with each of those IDPs Similarly, which end-point do we go to? Like for example, if you are federating with Facebook, how do you find the end-point? That is in the B2C Trust Framework Base-V2 There will be a reference from your Base-V1 policy to B2C Trust Framework, Base-V2 Trust Framework And that is the Trust Framework that we authored as part of the B2C offering That Trust Framework will have for example, the federation end-point to Facebook It will have what claims we are expecting How do we normalize those claims so that when we send them the token and one IDP is returning a first name while the other is returning a given name How do we normalize all of those? So all of that data goes into B2C Trust Framework This is the core concept under which we basically have build the B2C Trust Framework The Inheritance concept came

out of actually us trying to figured out how to manage these policies more effectively especially with multiple relying parties, each relying party wanting to do something slightly different yet using most of the stuff from other policies Generally, the way inheritance works in the framework is that every element will have an ID So for example, you might say that there is an identity provider that has an ID called Facebook-auth And every time another policy goes and says there is an identity provider with Facebook-auth It is providing the differential from the base policy So for example, if my policy declares a small section saying Facebook-auth and then a parent policy had Facebook-auth, my section is only going to give the differential And if it provides something that already exists in the base, it is going to override it And if something new is just going to add to it That’s generally how inheritance works I’ll show all of this with examples We have some special inheritance rules for collections Usually in the collections, we will append by default If you had a collection of three claims in the base policy and two more that the application needs, it becomes five But there are special rules around how you can just modify and override it And there’s a special inheritance rules around orchestration steps because they affect the user journey directly. So I’ll go over those as well Let me move forward and talk a little bit about user journeys Anytime an application sends a request to Azure Active Directory, B2C whether it’s an IEF policy or B2C policy There’s a policy ID that comes in the request And every policy that comes in the request that is requested by the application, must have what we call it default user journey So we will always go and look up inside that policy whether there’s a tag called default user journey The name of the tag is not important The important thing is that every request to the authorized end point, for example, in OAUTH 2.0 or whether you’re using SAML or something else has to identify a policy that must point to a user journey And user journey is essentially the user experience that the end user goes through So the user journey will define On the first screen, I want to show an option of all the different identity providers that a user sees On the second step, I want to actually federate have IEF federate with that identity provider So that’s my second step On the third step, I want to, for example, collect some additional claims Let me walk through a real example here So for example, the B2C tenant end-point in the very first step, gets a request And it’ll open up the user journey and go to the first step So this is the example of what I was saying could be an identity provider screen, where we show Facebook and Google and we say you can sign up using a local account or you can federate to your special SAML based, for example, IDP Then in a second step, we will basically go and federate with that IDP This is a typical flow It doesn’t have to be this way because you control your policy, you can modify your XML to do anything you want in first step I have worked with a customer who wanted in the very first step, they wanted to get the phone number, and then validated the phone number because they wanted to base their experience purely on the phone number And based on the phone number, they could immediately figure out whether the user account already exist If it existed, it’s a different flow If it does not exist, it’s a different flow And we made it work for that scenario as well And then after that, there will be another step in the user journey orchestration It could be, “I want to collect more claims I want to go and create an account in an external directly in a CRM system somewhere else.” And then when the journey ends, it’ll issue a token back to the application It’ll redirect back. It will have the token and the token may have some claims in it depending on the policy So this is what we’re trying to get from the policy that comes in the request That’s everything that the orchestration engine is thinking through Each one of these steps is going to make use of the rest of the Trust Framework policy which will include building blocks, claim types, everything else you saw on the slide that I showed earlier So the easiest way we find to debug policies is to go through user journeys first, figured out which user journey was invoked We’ll go through one example hopefully in this session And then from there, we can start figuring out what are all the references and then go through those

If you have questions, or if something doesn’t make sense, interrupt me along the way It will be easier because by the time I go to the end, I might have gone too far away And then it might be hard to recover And so, there is also this concept of preconditions A precondition before a user journey step specifies whether that user journey should be executed or not It’s similar to a conditional statement in a programming language, except that we don’t have blocks of conditions We just have one condition per step, or a set of conditions per step, not a block of steps A common condition is, for example, if the phone number scenario I was talking about earlier Once the phone number is verified by the user and it is looked up in a directory, a precondition would say, “If the user does not exist in the directory, create the account first and then move forward.” So that is how preconditions are normally applied in the context of a B2C policy or user journey LP, switch over to a Starter Pack This is what I was talking about when you start with custom policies, you’ll get a link to our Starter Pack documentation, and we have three or four different Starter Packs I’ll go into a bit more details about the quantities of Starter Packs and on But let me get to the policy first, and talk about the same thing in XML This is the user journeys we have in the Starter Pack, the policy have opened is the sign up and sign in Actually, let me see Go back to the slides first, and then I’ll come back to the policy Let me do a little bit of advantage, disadvantage discussion of the Starter Pack So, we have three or four different Starter Packs, the list of the Starter Packs is here The reason we gave these Starter Packs was because when we learn the private review, it turned out that a lot of people who were going through private review you did not have a very sort of easy way to manage the policies, and avail those starting point In some cases, we gave our legacy Trustframework, it turned out to be way too complex because we had some legacy reasons to keep a bunch of stuff in our Trustframework that does not make sense for somebody starting new We also found out that, as we modified our Trustframework and gave it out, anybody who had modified our previously given out Trustframework found it very difficult to integrate the new one, the new copy So, in the Starter Packs, we basically try to solve some of those problems One was that we will just give three or four Starter Packs as a common Starter Pack If you’re using social accounts only, just take the social accounts It will generally be less complicated than, for example, the social and local accounts with the MFA And it will be smaller, less to manage, but if you have a scenario where you want to do both social and local accounts, and you just pick social and local accounts, and then we will go with that And the Starter Packs have some pre-built user journeys The user journeys we have in Starter Packs are the same that we have in B2C portal The goal is that once you take the Starter Pack and you start with custom policies, you should have some parity with what you were getting through the portal So, that you can start from that point onward instead of starting from scratch So, we have typically two or three, I think three user journey to SignUpOrSignIn There’s a ProfileEdit And in the local accounts, there will be a password reset You can go through it and those user journeys are similar to what we have in B2C But like I was saying, for legacy reasons, we might have more than B2C Trustframework The Starter Pack simplifies that as well And the third is that we structured it for change management So, we created a Trustframework, we call it Trustframework base, and then, we provided an extensions to that Trustframework via the inheritance model I was talking about earlier So, as an example, in the base Trustframework we have a complete user journey that can do a SignUpOrSignIn flow or it can do a ProfileEdit flow It also has Facebook as an identity provider In the social accounts, we get Facebook as a default identity provider example So that, it contains the authorize endpoint and a few other settings for Facebook But it does not contain the client ID and the reference to the secret in your opinion because those are very specific to your set up In the extensions, you will typically end up providing other secret The reference from the secret in your content and the client ID So, the next time around,

we change the Trustframework This happened a couple of months back There was a breaking change where Facebook is the API version And once they changed the API version, the format of the token was a little bit different And you had to modify the Facebook IDP, protecting your profile, that IDP in the Trustframework, to basically process their response correctly So, we, at that point, are able to give a new Trustframework and you will typically be able to take the Trustframework in applying your and test it and then roll it out without having to make changes in the added extensions or in our policies So, we are trying to make it work We do get feedback from time to time from people who try the Trustframeworks We have gotten feedback about creating new user journeys That is something that we need to still work on We did get some feedback initially about change management There is a bunch of other feedback about change management but specifically, on Trustframework policies, there is more as people try We will definitely want to look into that So now, let me go to the walk-through Well, I was supposed to do it now not earlier So let me go through the walkthrough So, this is the sample Trustframework XML If you start a Starter Pack, then download Starter Pack and start playing with it It will come back with one, two, three, four, five XML files and out of each Trustframework base, has most of the content Since I’m looking at social and local accounts, this will have both at least one social account and a number of technical profiles for a local account When I say technical profile, I’ll talk about it in the context of claims providers later But think of technical profile as an endpoint to reach identity framework or identity experience framework we’ll federate with So for example, theoretically, Google has multiple endpoints It has all through that we’re already using There’s an open ID connect And I believe they also have a sample, one we’ve been off to an open ID connect Somebody could say I have one claims provider which is Google and then it has an open ID technical profile and then it has another technical profile for all two And then, each user journey can pick and choose between those two or even give that option to the user if it mattered at all So technical profile is really the endpoint that contains the federation metadata and claims provider is a generalization of whether you have an identity provider, an attribute provider, or an attribute verifier The difference between those two, typically, is that the identity provider would be usually like Facebook or Google with the use of Google to type some information and then Google will, in short, open to us This typically nevers any claims that are going in the request In the case of attribute verifier, that is possible It is possible that attribute verifier can behave both ways They can be attribute verifiers where IEF redirects to attribute verifier, and attribute verifier, the user provide some information And then, we get back a response with a token and then we start consuming that Or there could be some claims that go into that and attribute verifier because attribute verified can not trust anything that the user has given For example, it is possible that IEF authenticates a user, says this is user’s email address from our record, and then needs to send him back to the attribute verifiers so it can look up the town database from that email address So, that is how the attribute verifiers can also be logged in And same thing with attribute providers In many cases, the attribute providers and attribute verifiers can be the same So when we were looking at this whole model, given that we are working with us to an open ID connect and some of them support this scenario already, the claims provider is a generalization of whether you have an identity provider, an attribute verifier, and attribute provider And the difference would typically be whether IEF is sending claims to them which are signed in the token or not, and getting back claims as well or not So attribute verifier might not be done by claims It might only say, “Hey, this all looks good. You have success.”

Whereas, an attribute provider actually might be returning claims sometimes to IEF So for us, it’s much easier to think of all of this as claims providers and then taking the profiles We are taking a profile represents an actual endpoint and claims provider represents typically the entity, for example, Google or Facebook or Equifax or XP So in our policy, we have some basic Attributes on the root element which define the schema version that is being used, depend entirely on the policy ID The schema region here is used because we can have as we go and develop more features from time to time, it may be required for us to rub the schema in ways that it is not backward compatible So far we have not had the need to do it, but for our own validation, we actually created multiple schema versions for testing, and so wine-three is the schema version that we have made publicly available And as soon as IEF gets a policy ID request, it goes to read the policy The first thing it will do is look at the policy schema version then find the right schema and deserialization logic to consume that policy So that is the primary purpose of the schema here Tenant ID, policy ID is basically the tenant in which the policy resides in Policy ID is what will come in the request to find this policy Public policy URI is more for documentation purposes If somebody needs to publish their policy and they need to have a public URI, they can put it here so any author can look at it The main sections that if you remember on Jose’s slide before, where these four sections out of which three are in this policy The fourth one I’ll show you later We typically do not put the relying party section in the base Trustframework because in 90 percent of the cases, it has things that are specific to that particular application So we end up putting that in the application policies only So building blocks, then it has as was exactly the case on the slide, it has four sections, four or five sections This Claims Schema which will contain all the claimed types that this policy has to be able to deal with It has Claims Transformations It has Client Definitions The examples of Claims Transformations could be, let’s say you have a date of birth of a user, but it should not be sent to the application in a token But the application needs to know whether the user is 18 years of age or not or 30 years of age or not So they could be a transformation that takes that date of birth and either converts it into years, age, whatever you want to do, or just a claim saying is user above 30? Is user above 18? Is it true or false? Those kind of things are possible with Claims Transformations There are other examples Sometimes we have found it to be the case that we get a single email address from an identity provider, but the provider to which we are sending email address actually takes a collection or the other way around So the Claims Transformations allows the data hide manipulation as well Where you want to convert a single claim into a collection or extract something out of a collection as a single valued claim There are some specific examples for active directory We have to create what active directory calls user principle name When we are creating a user that federated using social IDP, in the directory, as of today it must also contain a UPN And since there is no real requirement of a UPN for a socially federating user, we actually create a random UPN There are some transformations that help us and are used like that They’re transformations that will created data structures specific to the social IDP including, social IDP user, including creating what we call an old set ID It is currently not exposed outside the system We are working to expose it to external third parties as well But there will be claims transformations that you will see It will say create alternative security ID So those are very specific to the directory The more time you spend with the directory in general, with graph any graph and of those you figured out that there are these claim types that need to be added just to make some things work I will not go through those in detail today, probably tomorrow when we go through

the claims provider sections Let me go through a sample UserJourney I’ll try to first explain the UserJourney I’m going to walk through, and then I’ll show the XML So the UserJourney I want to walk through is the sign up or sign in It is the most commonly used UserJourney In fact when we started B2C we only had a sign up UserJourney and a sign in UserJourney And we got a ton of feedback around the user experience being very weird because the user had to explicitly select, I wanted to sign up or sign in And then once they would go to an IDP screen where they had Facebook or Google or something else, and they had already signed up but they went to sign up and Facebook again, they would get an error saying you’re already signed up please go back and sign in And so sign up or sign in UserJourney was actually initially created to solve that problem When as soon as user lands on a page, it shows identity providers, which is very common user experience today, where you’ll see Facebook, Google or it will say log in with your own for example local account or if let’s say you are New York Times, I’m just picking a random example It might say, Google Facebook log in with your New York Times account That way you can provide your email address and password And then there will be another link at the bottom saying, don’t have an account, create one here, something like that So that is how the sign up or sign in user experience is created in B2C And this policy orchestrates that entire user experience and so it has a lot of preconditions around, what if this is a local account? When I say local account it was basically where I said create your own New York Times account or create your own stack overflow account So those are called local accounts in the directory There’s local account and there is a socially federated account Because there is this logic around social accounts and local accounts, we have a bunch of preconditions trying to figure out when a user federates through a social IDP, we want to immediately check in them directly whether they use exists or not And if the user exists, we take them through the sign in experience And if a user does not exist, the user account does not exist in the directory, then we take them through the sign up experience And that’s what makes the sign up or sign in a bit more complicated especially in the social and local accounts start up pack That’s why we have other start up packs where if you don’t need this, you only are dealing with local accounts or social accounts, then a lot of this policy becomes simpler Let me walk through the UserJourney This is basically how the actual UserJourney is authored in XML Of course I did spend a lot of time converting into English, so we can understand it now, so we’ll go through the English version first The first page will show the ID provider selection, the user sees the page, and then the user will, and it already will say, you have a question? >> [inaudible] >> Sorry I didn’t understand >> [inaudible] >> Oh I see. So I would say let’s skip it for now I think I’ll come back to that later because I’m also doing a little bit of time check I was joking with Jose that in America it’s almost sacred to have lunch between noon and one and I’m already hungry So I don’t want to hold everybody beyond one at least So I’ll basically come to that in another session probably So first page user is shown the ITP selection page and on that page there is also saying that there’s also two checkboxes one where they can write their user ID and their password and so user can immediately go and say my email address is this and the password is this and I want to sign in So if that happens which is the 1B section, then immediately B2C will try to log in the user and do a password check If the password fails, the user is still on step one, nothing has changed So user will still see an error saying incorrect credentials and user still has the options to either go to Facebook instead or then try their password again and whatnot So in the second step, we do a precondition where we say the user has already signed in and skipped the step This is unnecessary But if the user has not signed in, they will typically have selected a social ITP So we need to federate The reason this federation is a second step is because it’s a change in the user experience

User sees a browser change to Facebook, user will be rendered a new page instead of the second step which would be served by Facebook or Google or any other ITP you have So from a user experience point of view it changes It is also possible that in the first step, the user had said I want to create a new account So in the second step we will show a screen saying give your first name, last name, whatever else application needs and then the user can provide that information So then we go to step three In the step three we check that if it was a local account, we want to skip this step because we are basically trying to do two things at the same time One is if the user had selected social account, we are going into the directory trying to find out if the user exists If he doesn’t exist we need to create the user account But if its a local account, we need to skip that step So the third step will skip in the case of local account but its going to go and try to find the user using their social ID and this is the alternative security ID I was talking about We usually say AltsecID as short The actual long name in the directory is called alternative security ID The fourth step determines by this time we have already done a check in the directory to see if the social account exists or not- I mean if the users account exist in the directory or not If it does not exist, then that means the user has authenticated using a social ITP and we need to register the user So in the fourth step, there’s a registration page, with all the attributes that a user can provide and then attempt to create the account The fifth step is back about the local accounts By this time, if it was a social account, it has either we have already found in the directory or we have already created the account in the directory if it’s social account So we are still left with a local account where the local account sign in might have just happened So in the case of local account sign in, we go into the directory and try to read all the attributes based on the object ID of the user So the object ID was retrieved in the first step when the user did their username and password at that time you validated the password So during the validation of the password, users object ID is retrieved from the directory So in the fifth step, all those attributes are read The reason we have to add this additional step is that when we do an authentication in the first step to validate the user password, the token that comes back may not have all the attributes that are needed for the application For example the application might have said I want some custom attributes that have been created in the directory So in the first step, the token has very limited set of claims that are retrieved during password validation Fifth step actually goes to directory and gets all the claims that are required to be issued by IEF in the token In the sixth step which is almost the last step, if the user does not exist in the directory, then we create a social federate user in the directory This is a special case It’s hard to explain but I’ll try So there are two scenarios in the social ITP authentication case One scenario is when it’s a new user, you need to collect some attributes So a screen should be shown whereas there can be cases, there are applications that do not want to collect any attributes They just say hey select Facebook, whatever claims Facebook returns, don’t show user any other screen just land them in the application And so if that had happened, we would have skipped steps three, four, five, all of them But in that case the user account is still not created because when I was saying, for example Social account [inaudible] local account. Yes So in this case you get attributes of the social ITP from the user and in this case we sign up the user using the social ITP So we sign up the user using social ITP, we go and try to find it in the directory If we don’t find the account, you still have to create the account of the user in the directory And during this step, we can either show that page or skip that page So that is covered in the sixth step and in the last steps creates a jar token and sends it back to the application So this is one of the most complex user journeys Internally we have talked multiple times about simplifying how we are through user journeys then you have so many preconditions,

where we have a local account that is a registration what is a local account that is a sign in, what is a social account that’s a registration, what is a social account that is a sign in And if you add MFA or something else on top of it, it makes it even more complex So we’re trying to figure out how to simplify this further but as of now this is a very good example of how to at least make the existing preconditions work with the user journey I think you’re already almost out of time, so we should skip the XML and then we start the next section we can continue where we are leaving off I’ll go briefly through this again and then we can go into XML and then we can go into other sections If anybody has questions, I’m here If nobody is going to ask questions, we can have lunch then I’m here still You can just come here and ask me any questions you might have All right thank you everybody. Yes >> All the costume policies [inaudible] >>So what do you mean by DSL? >> Information [inaudible] >> I see >> [inaudible] >> I think that’s a good question for Jose And he is running away >> It is a good question We have that The reason that the complete DSL describe scenarios that we have not yet tested, so we’ve on purpose but this is going to change very quickly, have documented guides on how to do specific things rather than documented the full language where people got round to corner cases We had the experience doing the private review of a lot of corner cases that we didn’t want to kind of throw up on to the community all at once But we’re ready. I get it And in these sessions you’re going to see all the language described in the sessions We have enough slides that describe every element in detail but send me an email and I’ll send it to you >>Just as a follow up to that So if you download the starter pack, there’s also an XXD which describes each of the nodes I mean that’s not all complete How they all went together >> [inaudible] Right? >> Right >> Okay, [inaudible]

You Want To Have Your Favorite Car?

We have a big list of modern & classic cars in both used and new categories.