Управление доступом на основе ролей (RBAC) и Управление доступом на основе утверждений (CBAC) в ASP.NET MVC

Каковы основные преимущества использования CBAC по сравнению с RBAC ? Когда лучше использовать CBAC и когда лучше использовать RBAC?

Я пытаюсь понять общие концепции модели CBAC, но общая идея все еще не ясна для меня.

Я попытаюсь показать, как вы можете воспользоваться преимуществами контроля доступа на основе утверждений в контексте ASP.NET MVC.

Когда вы используете аутентификацию на основе ролей, если у вас есть действие для создания клиента, и вы хотите, чтобы люди, которые находятся в роли «Продажа», могли это делать, тогда вы пишете такой код:

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

Позже вы поняли, что иногда люди из роли «Маркетинг» должны иметь возможность создавать Заказчика. Затем вы обновляете свой метод действия таким образом

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

Теперь вы поняли, что некоторые маркетологи не должны иметь возможность создавать Заказчика, но невозможно назначить другую роль для тех, кто занимается маркетингом. Таким образом, вы вынуждены позволить всем маркетологам создавать клиентов.

Вы заметили еще одну проблему: всякий раз, когда вы решаете, что специалистам по маркетингу должно быть разрешено создавать клиентов, вы должны обновить все свои атрибуты MVC Action методы Authorize, скомпилировать ваше приложение, протестировать и развернуть. Несколько дней спустя вы решили, что не маркетинг, а какая-то другая роль должна быть разрешена для выполнения этой задачи, поэтому вы выполняете поиск в своей кодовой базе и удаляете все «Маркетинг» из атрибута «Авторизация» и добавляете новое имя роли в атрибут «Авторизация» ... Не здоровое решение. На этом этапе вы бы осознали необходимость контроля доступа на основе разрешений.

Управление доступом на основе разрешений - это способ назначения различных разрешений различным пользователям и проверки, имеет ли пользователь разрешение на выполнение действия из кода во время выполнения. После того, как вы назначаете различные разрешения различным пользователям, вы понимаете, что вам нужно разрешить некоторым пользователям выполнять некоторый код, если у пользователя есть какое-либо свойство, такое как «Пользователь Facebook», «Долгое время» и т. Д. Позвольте мне привести пример. Скажем, вы хотите разрешить доступ к определенной странице, если пользователь вошел в систему с помощью Facebook. Теперь, вы бы создали разрешение «Facebook» для этого пользователя? Нет, «Facebook» не похоже на разрешение. Является ли ? Скорее это звучит как претензия. В то же время, разрешения могут звучать как претензия тоже! Таким образом, лучше проверить претензии и разрешить доступ.

Теперь вернемся к конкретному примеру управления доступом на основе утверждений.

Вы можете определить некоторый набор требований как это:

"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer" .. и т. Д.

Теперь вы можете украсить свой метод действия следующим образом:

        [ClaimAuthorize(Permission="CanCreateCustomer")]
        public ActionResult CreateCustomer()
        {
            return View();
        }

(обратите внимание, [ClaimAuthorize (Permission = "CanCreateCustomer")] не может быть встроен в библиотеку классов MVC, я просто показываю в качестве примера, вы можете использовать некоторую библиотеку классов, которая имеет такое определение класса Attribute)

Теперь вы можете видеть, что метод действия CreateCustomer всегда будет нуждаться в разрешении «CanCreateCustomer», и он никогда не изменится или почти не изменится. Таким образом, в вашей базе данных вы создаете таблицу разрешений (заявок) и отношения прав доступа пользователей. Из вашей админ-панели вы можете установить разрешение (претензию) для каждого пользователя, который может делать что. Вы можете назначить разрешение (требование) CanCreateCustomer любому, кому вам нравится, и только разрешенный пользователь сможет создавать клиента, а разрешенный пользователь сможет создавать только клиента и ничего больше (если вы не назначите другие разрешения тому же пользователю).

Эта модель безопасности предлагает вам чистую практику кода. Более того, когда вы пишете свой метод действия, вам не нужно думать о том, кто может использовать этот метод, скорее вы всегда можете быть уверены, что тот, кто использует этот метод, будет иметь надлежащее разрешение (требование), данное администратором. Затем администратор может решить, кто и что сможет сделать. Не вы как разработчик. Вот как ваша бизнес-логика отделена от логики безопасности.

Всякий раз, когда кто-то входит в систему, ваше приложение будет проверять все доступные разрешения для этого пользователя, и этот набор разрешений (заявок) будет доступен в качестве дополнительных свойств текущего пользователя, вошедшего в систему (обычно набор заявок сохраняется в виде файла cookie для зарегистрированного пользователя), так что вам не нужно постоянно проверять набор разрешений из базы данных. Суть в том, что вы получаете больше контроля над своей логикой безопасности в приложении, если вы применяете доступ на основе утверждений, а не доступ на основе ролей. На самом деле, роль также может рассматриваться как претензия.

Если ваше приложение является очень небольшим приложением, в котором будет только 2 роли: клиент и администратор, и нет никаких шансов, что клиент сможет сделать что-то еще, кроме того, для чего он предназначен в вашем приложении, то, возможно, на основе ролей Контроль доступа будет служить цели, но по мере роста вашего приложения вы начнете чувствовать необходимость контроля доступа на основе утверждений в какой-то момент.

Я уже много раз реализовывал модели безопасности, и мне тоже пришлось обдумать эти концепции. Сделав это много раз, вот мое понимание этих концепций.

Каковы роли

Роль = Союз пользователей и прав.

С одной стороны, роль - это набор разрешений. Мне нравится называть это разрешением. При определении роли вы в основном добавляете в эту группу набор разрешений, поэтому в этом смысле роль является профилем разрешений.

С другой стороны, Роль также является коллекцией пользователей. Если я добавлю Боба и Алису в роль «Менеджеры», тогда «Менеджеры» теперь содержат коллекцию из двух пользователей, вроде группы.

Правда в том, что Роль - это ОБА совокупность пользователей и совокупность разрешений вместе взятых. Визуально это можно рассматривать как диаграмму Венна.

Что такое группа

Группа = Коллекция пользователей

«Группа» - это строго группа пользователей. Разница между группой и ролью заключается в том, что у роли также есть коллекция разрешений, а у группы - только коллекция пользователей.

Что такое разрешение

Разрешение = Что может сделать субъект

Что такое набор разрешений

Набор разрешений = набор разрешений

В надежной системе RBAC разрешения также могут быть сгруппированы как пользователи. В то время как группы представляют собой набор только пользователей, набор разрешений представляет собой набор только разрешений. Это позволяет администратору добавлять целые коллекции разрешений к ролям одновременно.

Как пользователи, группы, роли и разрешения объединяются

В надежной системе RBAC пользователи могут быть добавлены в роль индивидуально для создания коллекции пользователей в роли, а группы могут быть добавлены в роль для одновременного добавления коллекции пользователей в роль. В любом случае, Роль получает свою коллекцию пользователей от индивидуального добавления, добавления групп в роль или добавления сочетания пользователей и групп в роль. Разрешения могут быть рассмотрены таким же образом.

Разрешения могут быть добавлены к ролям индивидуально для создания коллекции разрешений внутри роли или наборы разрешений могут быть добавлены к роли. Наконец, в роль могут быть добавлены наборы разрешений и наборов разрешений. В любом случае, Роль получает свою коллекцию разрешений от индивидуального добавления или добавления наборов разрешений в роль.

Вся цель ролей состоит в том, чтобы женить пользователей на разрешениях. Следовательно, роль - это СОЮЗ пользователей и разрешений.

Какие претензии

Претензия = Что такое "субъект"

Претензии не являются разрешениями. Как указывалось в предыдущих ответах, Претензия - это то, что субъект "является", а не то, что субъект "может сделать".

Претензии не заменяют роли или разрешения, они представляют собой дополнительную информацию, которую можно использовать для принятия решения об авторизации.

Когда использовать претензии

Я считаю, что Претензии полезны, когда необходимо принять решение об Авторизации, когда Пользователь не может быть добавлен в Роль, или если решение не основано на привязке Пользователя к Разрешению. Пример пользователя Facebook вызывает это. Пользователь Facebook не может быть кем-то, кто добавлен в «Роль» ... он просто какой-то посетитель, прошедший проверку подлинности через Facebook. Хотя это не вписывается в RBAC, это часть информации, по которой необходимо принять решение об авторизации.

@CodingSoft использовал метафору ночного клуба в предыдущем ответе, который я хотел бы расширить. В этом ответе водительское удостоверение использовалось в качестве примера, в котором содержался набор утверждений, где дата рождения представляет собой одно из утверждений, а значение требования DateOfBirth используется для проверки на соответствие правилу авторизации. Правительство, выдавшее водительское удостоверение, является органом, обеспечивающим достоверность претензии. Таким образом, в сценарии с ночным клубом вышибала у двери смотрит на водительское удостоверение человека, гарантирует, что оно было выдано доверенным органом, проверяя, является ли это поддельным ID (т. Е. Должен быть действительным выданным правительством ID), затем смотрит на дату рождения (одна из многих претензий на водительские права), а затем использует это значение, чтобы определить, достаточно ли взрослый человек, чтобы войти в клуб. Если так,

Теперь, имея в виду эту базу, я бы хотел расширить это. Предположим, что в здании, где находится ночной клуб, есть офисы, комнаты, кухня, другие этажи, лифты, подвал и т. Д., Куда могут войти только сотрудники клуба. Кроме того, некоторые сотрудники могут иметь доступ к определенным местам, а другие - нет. Например, менеджер может иметь доступ к офисному этажу выше, к которому другие сотрудники не могут получить доступ. В этом случае есть две роли. Менеджер и сотрудник.

В то время как доступ посетителей в общественную зону ночного клуба разрешается одной претензией, как объяснено выше, сотрудникам необходим доступ с помощью ролей в другие непубличные комнаты с ограниченным доступом. Для них водительских прав недостаточно. Им нужен значок сотрудника, который они сканируют, чтобы войти в двери. Где-то есть система RBAC, которая предоставляет бейджам в роли менеджера доступ на верхний этаж, а бейджам в роли сотрудника - доступ к другим комнатам.

Если по какой-либо причине определенные комнаты должны быть добавлены / удалены ролью, это можно сделать с помощью RBAC, но это не подходит для претензии.

Разрешения в программном обеспечении

Кодирование ролей в приложении - плохая идея. Это жестко кодирует цель роли в приложении. Приложение должно иметь только разрешения, которые действуют как функциональные флаги. В тех случаях, когда флаги функций становятся доступными посредством конфигурации, разрешения становятся доступными благодаря контексту безопасности пользователя, который определяется коллекцией разрешений DISTINCT, собранных для всех ролей, в которые был помещен пользователь. Это то, что я называю «эффективными разрешениями». Приложение должно только представить менювозможных разрешений на функции / действия. Система RBAC должна выполнять работу по объединению этих разрешений с пользователями через роли. Таким образом, не существует жесткого кодирования ролей, и единственный раз, когда меняется разрешение, это когда оно удаляется или добавляется новое. После того, как разрешение добавлено в программное обеспечение, оно никогда не должно изменяться. Его следует удалять только при необходимости (т. Е. Когда функция прекращается в новой версии), и можно добавлять только новые.

Последнее замечание

Грант против Дени

Надежная система RBAC и даже система CBAC должны различать гранты и отказы.

Добавление разрешения к роли должно сопровождаться либо GRANT, либо DENY. Когда разрешения проверены, все предоставленные разрешения должны быть добавлены в список пользователей действующих разрешений. Затем, после того, как все это будет сделано, список ЗАКЛЮЧЕННЫХ разрешений должен заставить систему удалить эти разрешения из списка действующих разрешений.

Это позволяет администраторам «настраивать» окончательные разрешения субъекта. Лучше всего, если разрешения также могут быть добавлены непосредственно к пользователям. Таким образом, вы можете добавить пользователя к роли менеджера, и он получит доступ ко всему, но, возможно, вы захотите ДЕНЬ получить доступ к женской уборной, потому что пользователь - мужчина. Таким образом, вы добавляете мужчину-пользователя в роль менеджера и добавляете разрешение для объекта пользователя с помощью DENY, чтобы он лишал доступ только комнаты этой леди.

На самом деле, это был бы хороший кандидат на претензию. Если у пользователя есть претензия «пол = мужчина», то присутствие в роли менеджера дает доступ ко всем комнатам, но в туалете Леди также требуется претензия пол = женщина, а в мужской комнате требуется претензия пол = мужчина. Таким образом, не нужно было бы настраивать разрешение DENY для пользователей-мужчин, так как принудительное применение претензий заботится об этом для всех с одним правилом авторизации. Тем не менее, это может быть сделано в любом случае.

Дело в том, что с DENIAL of Permissions облегчает управление ролями, потому что исключения могут быть реализованы.

Ниже приведена схема, которую я сделал давным-давно, которая показывает модель RBAC. У меня нет графика для утверждений, но вы можете себе представить, что это просто атрибуты, прикрепленные к пользователям, где бы они ни находились. Кроме того, на диаграмме не отображаются группы (мне нужно обновить ее в какой-то момент).

Надеюсь, это поможет.

Это схема описанного выше RBAC

Обновление от 7 апреля 2019 г. Основано на отзывах @Brent (спасибо) ... убрал ненужные ссылки на предыдущие ответы и объяснил оригинальную основу метафоры «ночной клуб», предоставленной @CodingSoft, чтобы сделать этот ответ понятным без необходимости читать другие ответы.

Я не полностью согласен с ответом Эмрана

[Authorize(Roles="Sale")]

Наивный

Вопрос в том, как

  [Authorize(Roles="CustomerCreator")]

отличается от

 [ClaimAuthorize(Permission="CanCreateCustomer")]

Если оба одинаково хороши, зачем нам требовать?

Я думаю потому что

Концепция претензий является более общей по сравнению с ролью

В контексте приведенного выше примера мы можем сказать, что «CustomerCreator» является заявкой типа «роль», предоставленной «Asp.NETroleProvider»

Дополнительные примеры претензий.

1. «AAA» является заявкой типа «MYExamSite.Score», предоставленной «MYExamSite.com»

2. «Gold» - это претензия типа «MYGYM.Membershiptype», предоставленная «MYGYMApp»

Принятый ответ, по-видимому, позиционирует роли как тупой объект, а претензии - как гибкий инструмент, но в остальном делает их почти идентичными. К сожалению, такое позиционирование оказывает плохую услугу понятию требований и может в основном отражать небольшое недопонимание их цели.

Роли существуют и имеют смысл только в неявном объеме. Обычно это прикладная или организационная сфера (т. Е. Роль = администратор). Заявки, с другой стороны, могут быть «сделаны» кем угодно. Например, аутентификация Google может выдвигать претензии, включая «электронную почту» пользователя, таким образом прикрепляя это электронное письмо к личности. Google предъявляет претензии, приложение выбирает, следует ли понимать и принимать это требование. Само приложение может впоследствии присоединить утверждение под названием «метод аутентификации» (как это делает ASP.NET MVC Core Identity) со значением «Google». Каждая претензия включает объем, чтобы можно было определить, имеет ли претензия значение внешне, локально или и то, и другое (или более детально по мере необходимости).

Ключевым моментом является то, что все утверждения явно привязаны к идентичности и включают в себя явный объем. Эти утверждения, конечно, могут быть использованы для авторизации, и ASP.NET MVC обеспечивает их поддержку с помощью атрибута Authorize, но это не единственная или не обязательно основная цель утверждений. Это, конечно, не отличает его от ролей, которые могут использоваться точно так же для локальной авторизации.

Таким образом, можно использовать Роли, или Заявки, или и то, и другое для целей авторизации, и, вероятно, не обнаруживать присущих им преимуществ или недостатков, при условии, что эти Роли и Заявки ограничены локально. Но если, например, авторизация зависит от внешних требований идентификации, то роли будут неадекватными. Вам придется принять внешнюю заявку и перевести ее в роль с локальной областью. В этом нет ничего плохого, но он вводит слой косвенности и отбрасывает контекст.

В более широком смысле следует рассмотреть управление доступом на основе атрибутов (ABAC). RBAC и ABAC являются концепциями, определенными NIST, Национальным институтом стандартов и технологий. CBAC, с другой стороны, является моделью, продвигаемой Microsoft, которая очень похожа на ABAC.

Узнайте больше здесь:

• Страница NIST на основе управления доступом на основе ролей
• Страница NIST управления доступом на основе атрибутов

Принципиальное значение между RBAC и CBAC заключается в том, что:

RBAC : пользователь должен быть назначен на роль, которая будет авторизована для выполнения действия.

CBAC : пользователь должен иметь заявку с правильным значением, как ожидается приложением, для авторизации. Контроль доступа на основе утверждений элегантен в написании и прост в обслуживании.

Кроме того, претензии предъявляются к приложению службами выдачи разрешений (токен службы безопасности STS), которым доверяет ваше приложение (проверяющая сторона)

Роль - это всего лишь один из видов претензий. Таким образом, может быть много других типов утверждений, например, имя пользователя является одним из типов утверждений.

Важно сначала проанализировать, для чего требуется аутентификация, прежде чем выбирать, какой метод лучше. Из приведенной ниже документации Microsoft говорится: «Претензия - это не то, что может сделать субъект. Например, у вас может быть водительское удостоверение, выданное местным органом по выдаче водительских прав. В вашей водительской лицензии указана дата вашего рождения. В этом случае имя претензии будет DateOfBirth, значением претензии будет ваша дата рождения, например, 8 июня 1970 г., а эмитентом будет орган, обеспечивающий получение водительских прав. Авторизация на основе утверждений, в самом простом виде, проверяет значение претензии и предоставляет доступ к ресурс, основанный на этом значении. Например, если вы хотите получить доступ к ночному клубу, процесс авторизации может быть следующим: 6 "

Из этого примера мы видим, что доступ к ночному клубу с авторизацией на основе утверждений отличается от того типа авторизации, который потребуется сотрудникам, работающим в ночном клубе, в этом случае персоналу ночного клуба потребуется авторизация на основе ролей, которая не требуется для посетителей ночного клуба, поскольку все посетители ночного клуба имеют общую цель в ночном клубе, поэтому в этой ситуации авторизация на основе заявок подходит для посетителей ночного клуба.

Авторизация на основе ролей https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles 14.10.2016 При создании удостоверения оно может принадлежать одной или нескольким ролям. Например, Трейси может принадлежать к роли администратора и пользователя, а Скотт может принадлежать только к роли пользователя. Как эти роли создаются и управляются, зависит от резервного хранилища процесса авторизации. Роли предоставляются разработчику с помощью метода IsInRole класса ClaimsPrincipal.

Авторизация на основе утверждений https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims 14.10.2016 При создании удостоверения ему может быть назначено одно или несколько утверждений, выданных доверенной стороной. Претензия - это пара имя-значение, представляющая субъекта, а не то, что субъект может сделать. Например, у вас может быть водительское удостоверение, выданное местным органом управления водительскими правами. В вашем водительском удостоверении указана дата вашего рождения. В этом случае именем претензии будет DateOfBirth, значением претензии будет ваша дата рождения, например, 8 июня 1970 г., а эмитентом будет орган, имеющий водительские права. Авторизация на основе утверждений, в самом простом случае, проверяет значение утверждения и предоставляет доступ к ресурсу на основе этого значения. Например, если вы хотите получить доступ к ночному клубу, процесс авторизации может быть следующим:

Офицер охраны дверей оценит стоимость вашего заявления о дате рождения и будет ли он доверять эмитенту (органу, управляющему водительскими правами), прежде чем предоставить вам доступ.

Идентификатор может содержать несколько утверждений с несколькими значениями и может содержать несколько утверждений одного типа.

Также возможно управлять ролями в форме требований.

Вместо создания ролей авторизации, которые отражают бизнес-роль, создайте роли, которые отражают роли действий, например, CreateCustomer, EditCustomer, DeleteCustomer. Аннотируйте методы по мере необходимости.

Нелегко сопоставить отдельных лиц с набором ролей действий, особенно по мере того, как список ролей увеличивается. Поэтому вам необходимо управлять бизнес-ролями на более низком уровне детализации (например, «Продажи», «Маркетинг») и сопоставлять бизнес-роль с требуемыми ролями действий. Т.е. добавить пользователя в бизнес-роль, и он сопоставит его с требуемыми ролями (действиями) в существующей таблице авторизации.

Вы даже можете переопределить бизнес-роль и напрямую добавить человека в роль действия.

Поскольку вы строите поверх того, что уже работает, вы не отменяете существующий процесс авторизации. Вам нужно всего лишь несколько таблиц для реализации этого подхода

Я думаю, что на этот вопрос можно ответить с точки зрения базы данных. Если вы заметили, как таблицы, участвующие в этой имплантации, вы найдете следующее

1. AspNetUsers: у каждого пользователя есть одна строка со всеми атрибутами, необходимыми для всех пользователей, такими как электронная почта, адрес телефона, пароль .....
2. AspNetRoles; определяет различные роли в соответствии с требованиями приложения, такими как GM, CTO, HRM, ADMIN, EMP. что определяет каждая роль в соответствии с потребностями приложения.
3. AspNetUserRoles: каждая строка связывает AspNetUsers и AspNetRoles и эффективно связывает между одним пользователем и многими ролями.
4. AspNetUserClaims: каждая строка имеет ключ к AspNetUsers и один тип и значение. так эффективно добавьте один атрибут для каждого пользователя, который может быть добавлен / удален во время выполнения.

Использование этих таблиц может быть изменено в один момент времени жизни пользователя / приложения в соответствии с конкретными потребностями.

Рассмотрим раннюю стадию «Менеджер по закупкам» (PM), у нас может быть три подхода

1. Приложение заполняет AspNetUserRoles одной строкой, чтобы предоставить «PM» право на покупку. Чтобы оформить заказ на покупку на любую сумму, пользователю требуется только роль «ПМ».

2. Приложение заполняет AspNetUserRoles одной строкой, чтобы предоставить «PM» право на покупку, и заполняет AspNetUserClaims заявку типа TYPE «Закупочная сумма» и значением «<1000» для установки предела суммы. Чтобы оформить заказ на поставку, пользователь должен иметь «PM», а сумма заказа должна быть меньше суммы претензии ТИП претензии «Сумма закупки».

3. Приложение заполняет AspNetUserClaims заявкой типа TYPE «Закупочная сумма» и значением «<1000». Любой пользователь может оформить заказ на поставку, если сумма этого платежа меньше суммы претензии ТИП «Сумма закупки» для этого пользователя.

Как можно заметить, на основе ролей имеются грубые права, которые упростили бы жизнь пользователя приложения с точки зрения управления системой. однако это ограничит возможности пользователя с точки зрения бизнес-требований. С другой стороны, претензии на основе очень тонких прав, которые должны быть назначены каждому пользователю. претензии на основе будут слишком ограничивать бизнес, однако сделают управление системой очень сложным.

Управление доступом на основе ролей (RBAC)

В вашей организации вы можете иметь следующие роли

Наемный рабочий

Управляющий делами

HR

В зависимости от роли или ролей, к которым принадлежит зарегистрированный пользователь, вы можете разрешать или запрещать доступ к определенным ресурсам в приложении. Поскольку мы используем роли для проверки авторизации, это обычно называется контролем доступа на основе ролей (RBAC) или авторизацией на основе ролей.

В ASP.NET Core для реализации авторизации на основе ролей мы используем атрибут Authorize с параметром Roles.

[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}

Контроль доступа на основе утверждений (CBAC)

ЧТО ТАКОЕ Претензия? Заявка - это пара имя-значение. Это действительно часть информации о пользователе, а не о том, что пользователь может и не может сделать. Например, имя пользователя, адрес электронной почты, возраст, пол и т. Д. - все это претензии. То, как вы используете эти претензии для проверки авторизации в вашем приложении, зависит от требований вашего бизнеса и авторизации.

Например, если вы создаете портал для сотрудников, вы можете разрешить вошедшему в систему пользователю подать заявление на отпуск по беременности и родам, если в качестве значения требования для пола указано «женщина». Точно так же, если вы создаете приложение электронной коммерции, вы можете разрешить вошедшему в систему пользователю отправлять заказ, если значение возрастного требования больше или равно 18.

Претензии основаны на политике. Мы создаем политику и включаем в нее одну или несколько претензий. Затем политика используется вместе с параметром политики атрибута Authorize для реализации авторизации на основе утверждений.

[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}