> ## Documentation Index > Fetch the complete documentation index at: https://docs.iru.com/llms.txt > Use this file to discover all available pages before exploring further. # Quickstart > Go from an empty Iru Identity tenant to a working single sign-on launch for your first app: add users, assign access, and test the sign-in flow end to end. This quickstart walks through the shortest path to a working sign-on: add a person, group them, connect an application, grant access, protect it with a policy, and verify the experience. Each step links to a deeper guide when you want more detail. You need administrator access to your Iru tenant to follow these steps. If you manage admins separately, see [Administrators & roles](/en/identity/administration/administrators-and-roles). ## Before you begin You can add users by hand, import them from a file, or sync them from a connected HR system. For this quickstart, adding one user by hand is enough. To bring in your whole organization later, see [Importing users](/en/identity/directory/importing-users) and [Directory Sync](/en/identity/directory/directory-sync). Most applications support either SAML or OIDC for single sign-on. Have the app's documentation handy, or use a ready-made [application template](/en/identity/applications/application-templates) so the fields are filled in for you. ## Set up your first sign-on In **Directory → Users**, create a user with a name and email address. Use an address the person can actually receive mail at, so they can complete their invitation. The user's profile holds the attributes that policies and apps can use later. Learn more in [Users](/en/identity/directory/users). In **Directory → Groups**, create a group and add your user to it. Assigning access to groups instead of individuals keeps things manageable as you grow. See [Groups](/en/identity/directory/groups). In **Apps**, add an application. Choose a template from the catalog when one exists, or configure a custom SAML or OIDC app. Iru gives you the sign-on details to enter in your app, and you enter the details your app provides back into Iru. See [Add an application](/en/identity/applications/applications-overview). Assign the group you created to the application. Everyone in the group now has access; from then on you manage who can reach the app by changing the group's membership. See [Assigning access](/en/identity/applications/assigning-access). In **Policies → Authentication policies**, create a policy and attach it to your app to control **device trust** - for example, requiring a managed, encrypted device for a sensitive app. A passkey or Iru Access is already required for every sign-in, so you do not configure that here. See [Authentication policies](/en/identity/authentication/authentication-policies). Sign in as your test user and open the app dashboard. Your application appears as a tile; selecting it signs the user straight in. See [End-user experience](/en/identity/administration/end-user-experience). To exercise device trust and the full sign-in experience, install **Iru Access** on your test device and register it - see [Authenticators](/en/identity/authentication/authenticators). ## What you just built ```mermaid theme={null} flowchart LR user["Test user"] --> group["Group"] group --> assign["Assigned to app"] policy["Authentication policy"] --> assign assign --> app["Single sign-on"] ``` You now have a person who belongs to a group, a group that is granted an application, and a policy that governs how they sign in. Adding more people or apps is a matter of repeating the parts you need. ## Next steps Import your full user list or sync it from your HR system so the directory stays current on its own. Let people sign in with Google Workspace, Microsoft Entra ID, or another provider you already run. Provision and deprovision accounts in your apps automatically as access changes. Add risk and device trust conditions so access adapts to context.