Разработка модуля авторизации пользователей и разграничения прав доступа к данным – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка

Что будет представлять из себя приложение

Сайт со следующими страницам:

Описание основных используемых аннотаций

Controller

Что такое аутентификация?

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

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

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

Основные поля

Кратко остановимся на том, какие есть стандартные полях в токене и зачем они нужны:

Модуль авторизации

Магистрант группы ЕТ-222


Мидоночева Н.С.

Челябинск, 2022

Авторизация

Авторизация – процесс определения достоверности полномочий предъявителя на

доступ к ресурсу или использованию услуг [1].

Создание нового проекта в IDE


Мы будем использовать систему сборки Maven.

Под GroupId подразумевается уникальный идентификатор компании (или ваше личное доменное имя), которая выпускает проект. ArtefactId – это просто название нашего проекта.

После завершения создания проекта отроется файл pom.xml, Idea предложит включить автоимпорт – не отказывайтесь. В этом файле будут содержаться все зависимости (библиотеки), используемые в проекте.

Плюсы и минусы авторизации

Некоторым людям не нравится проходить авторизацию из-за нежелания указывать

личные данные или же из-за лени, поэтому сайты, скрывающие свою информацию от

незарегистрированных пользователей, теряют часть клиентов. Однако есть и польза от

авторизации – она помогает уменьшить объём спама в темах сайта, который оставляют

Создание структуры проекта (пакетов)


Сразу перейдем к созданию пакетов. Структура проекта, которая должна получиться показана ниже.

Теперь коротко о том, что будет храниться в каждом пакете:

Рассмотрим файл

pom.xml

. В этом файле нужно указать ссылку на родительский файл с помощью тега

parent

, т.о. все свойства и зависимости родителя будут добавлены в этот дочерний файл.


Далее добавляем зависимости для работы модулей Spring, драйвер БД PostgreSQL, сервера Tomcat, JSTL.

По умолчанию maven будет использовать старую версию java 1.6, чтобы это исправить указываем версию явно.

Также добавляем плагин, позволяющий упаковывать архивы jar или war и запускать их «на месте»:


Заполним файл

application.properties

Модуль авторизации

Модуль – это небольшой блок, отображаемый на какой-либо заранее

определенной в шаблоне позиции, расширяющий возможности компонентов и

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

части системы.


Модуль авторизации отображает форму авторизации. Он также показывает

ссылку на получение забытого пароля. Если регистрация пользователей

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

саморегистрации.


Также в модуле авторизации может присутствовать чекбокс «Запомнить меня»

1. Добавление сущностей (моделей)

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

Для импорта необходимых классов и библиотек используем комбинацию клавиш Alt Enter.

Разработка модуля авторизации пользователей и разграничения прав доступа к данным – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка

2. Реализация слоя доступа к данным и сервисного слоя

Spring Data предоставляет набор готовых реализаций для создания слоя, обеспечивающего доступ к БД. Интерфейс

JpaRepository

предоставляет набор стандартных методов (findBy, save, deleteById и др.) для работы с БД.

3. Добавление контроллеров


Для страниц, которые никак не обрабатываются сервером, а просто возвращают страницу, маппинг можно настроить в конфигурации. Страница

login

обрабатывается Spring Security контроллером по умолчанию, поэтому для неё отдельный контроллер не требуется.

@Configuration
public class MvcConfig implements WebMvcConfigurer {

    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/login").setViewName("login");
        registry.addViewController("/news").setViewName("news");
    }
}

RegistrationController.

Отдельный контроллер нужен для страницы регистрации. Для обработки GET запроса используется аннотация

@GetMapping(“/registration”)

, для POST –

@PostMapping(“/registration”)


Чтобы что-то добавить или получить со страницы мы обращаемся к model. В GET запросе на страницу добавляется новый пустой объект класса

4. Добавление представлений

index.jsp

Запуск приложения

В main класс Application нужно добавить следующее:

Типовые поля формы авторизации

Поля ввода данных (обычно это

Назначение модуля авторизации

Модуль авторизации необходим для разграничения возможностей пользователей на

просмотр данных приложения, веб-страницы и т.д.


Типовой цикл работы модуля авторизации:

Происходит загрузка формы авторизации;

Литература

1. ГОСТ Р 53632-2009: Показатели качества услуг доступа в Интернет. Общие требования

Forms authentication

Разработка модуля авторизации пользователей и разграничения прав доступа к данным – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка

Token authentication

Разработка модуля авторизации пользователей и разграничения прав доступа к данным – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка

Следующее поколение способов аутентификации представляет Token Based Authentication, который обычно применяется при построении систем Single sign-on (SSO). При его использовании запрашиваемый сервис делегирует функцию проверки достоверности сведений о пользователе другому сервису. Т. е. провайдер услуг доверяет выдачу необходимых для доступа токенов собственно токен-провайдеру (Identity provider).

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

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

На следующей схеме дополнительно отражены те этапы взаимодействия, в которых пользователь принимает непосредственное участие. Этот момент и является недостатком подобной схемы — нам всегда нужен пользователь, чтобы получить доступ к ресурсу.
Разработка модуля авторизации пользователей и разграничения прав доступа к данным – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка

Vuex модуль авторизации

Во-первых, давайте настроим наш файл store.js для vuex:

Взгляд сверху

Picture7

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

Запрос на аутентификацию

Authentication/Token Request — процесс запроса аутентификации.

В зависимости от того какие области (scopes) запрошены, сервис выдачи токенов вернет:

  1. Только Identity Token, если запрошены только Identity scopes.
  2. Identity Token и Access Token, если запрошены также и Resources scopes.
  3. Access Token и Refresh Token, если запрошeн Offline Access.


Более подробно про процесс аутентификации можно прочесть в разделе «

Используемые источники

  1. Registration and Login with Spring Boot, Spring Security, Spring Data JPA, Hibernate, MySQL, JSP, Bootstrap and Docker Compose
  2. Обратная сторона Spring
  3. Spring Security/Технический обзор Spring Security
  4. Официальная документация Spring
  5. Учимся готовить: Spring 3 MVC Spring Security Hibernate

Клиент

Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «

» у которого клиент запрашивает токен для доступа).

Компонент login

Создайте файл Login.vue в каталоге ./src/components. Затем добавьте в него шаблон для страницы входа:

Компонент register

Как и компонент для входа в систему, давайте сделаем такой же для регистрации пользователей. Начните с создания файла Register.vue в каталоге компонентов:

Далее определим атрибут data, который будем связан с формой:

Компонент secure

Далее создадим простой компонент, который будет отображаться только в случае аутентификации нашего пользователя. Создайте файл компонента Secure.vue и добавьте в него следующее:

Настройка axios

Нам понадобятся axios во многих наших компонентах. Давайте настроим его на начальном уровне, чтобы нам не приходилось импортировать его каждый раз, когда он нам нужен.

Откройте файл ./src/main.js и внесите в него следующие изменения:

Настройка модулей приложения

Для этого проекта мы хотим создать приложение vue с vuex и vue-router. Мы будем использовать vue cli 3.0, чтобы создать новый проект vue и выбрать опции router и vuex.

Запустите следующую команду, чтобы создать проект:

$ vue create vue-auth

Следуйте появившемуся диалоговому окну, введите необходимую информацию, выберите нужные параметры (vuex, vue-router) и завершите установку.

Далее, установите axios:

$ npm install axios --save

Настройка сервера для аутентификации

Как настроить Node сервер для обработки аутентификации я уже писал в другой статье Vue Authentication And Route Handling Using Vue-router в разделе Setup Node.js Server

Немного информации о spring security

Самым фундаментальным объектом является

SecurityContextHolder

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

Authentication

, пользователя авторизованной сессии.

Немного теории.


Начнем с небольшой теоретической части. В платформе ASP.NET MVC существует несколько видов аутентификации, предоставляемой из коробки.

В аутентификации через форму на стороне клиента хранит зашифрованный cookie-набор. Cookie передается в запросах к серверу, показывая, что пользователь авторизован. Для создания такого зашифрованного набора, в стандартной аутентификации через форму, служит метод Encript в классе System.Web.Security.

Похожее:  МТС домашний интернет — личный кабинет

FormAuthentication. Для декодирования используется метод Decrypt. Чем хорош класс FormAuthentication? Тем, что его методы кодирования и декодирования шифруют и подписывают данные с помощью машинных ключей сервера. Без данных ключей информацию из cookie файла невозможно прочесть или изменить, а нам не нужно изобретать велосипед.

Область (scope)

Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес

в составе

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

Scopes бывают двух видов:

  1. Identity scopes — это запрос информации о пользователе. Его имя, профиль, пол, фотография, адрес электронной почты и т. д.
  2. Resource scopes — имена внешних ресурсо (Web APIs), к которым клиент хочет получить доступ.

Обновим компонент app

Откройте файл ./src/App.vue и добавьте в него следующее:

Можете ли вы увидеть ссылку Logout, которую мы установили, чтобы показываться только в том случае, если пользователь вошел в систему? Отлично.

Теперь, давайте добавим логику для выхода из системы:

Тут мы делаем две вещи — вычисляем состояние аутентификации пользователя и запускаем действие logout, когда пользователь нажимает кнопку logout. После выхода из системы мы отправляем пользователя на страницу входа с помощью this.$router.push(‘/login’).

Теперь давайте создадим модуль авторизации, используя vuex.

Обработка просроченных токенов

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

Откройте файл ./src/App.vue и добавьте в него следующее:

Обработка случаев несанкционированного доступа

Мы определили наши маршруты. Теперь давайте проверим несанкционированный ли доступ и примем меры. В файле router.js добавьте следующее перед export default router:

router.beforeEach((to, from, next) => {
  if(to.matched.some(record => record.meta.requiresAuth)) {
    if (store.getters.isLoggedIn) {
      next()
      return
    }
    next('/login') 
  } else {
    next() 
  }
})

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

Определение маршрутов для аутентифицированных и неаутентифицированных страниц

Откройте файл ./src/router.js и импортируйте то, что нам нужно для этой настройки:

import Vue from 'vue'
import Router from 'vue-router'
import store from './store.js'
import Home from './views/Home.vue'
import About from './views/About.vue'
import Login from './components/Login.vue'
import Secure from './components/Secure.vue'
import Register from './components/Register.vue'

Vue.use(Router)

Как вы можете видеть, мы импортировали vue, vue-router и нашу настройку vuex store. Мы также импортировали все определенные нами компоненты и установили vue для использования нашего маршрутизатора.

Давайте определим маршруты:

[...]
let router = new Router({
  mode: 'history',
  routes: [
    {
      path: '/',
      name: 'home',
      component: Home
    },
    {
      path: '/login',
      name: 'login',
      component: Login
    },
    {
      path: '/register',
      name: 'register',
      component: Register
    },
    {
      path: '/secure',
      name: 'secure',
      component: Secure,
      meta: { 
        requiresAuth: true
      }
    },
    {
      path: '/about',
      name: 'about',
      component: About
    }
  ]
})

export default router

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

Предварительные требования

  1. Знание JavaScript
  2. Установленный Node
  3. Знания Vue
  4. Установленный Vue CLI

Пример использование


Восновном все реализация для конкретного проекта, заключается в прописание нужных generic типов.

Первое с чего будем начинать во всех проектах, это реализация класса идентификации.

Реализация модуля аутетификации


Пример сервиса авторизации.

Базовый контроллер для текущего проекта

Ну и реализуем атрибут с правилами аутентификации

Процесс аутентификации

Picture9

Разбираемся детально ху из ху

В данный момент на слуху следующие протоколы:

  1. OpenID — для проверки учетных данных пользователя (identification & authentication).
  2. OAuth — про то, чтобы получать доступ к чему-то.
  3. OpenID Connect — и про и то, и про другое одновременно.

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

УДК 519.6:004.4

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

Д.Е. Белов, к. б. н.,

А.Ф. Шалин, гл. специалист по информационной безопасности

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

Вместе с положительными аспектами развития информационных технологий открывается ряд проблем, связанных с контролем данных. А именно, их целостности и непротиворечивости, особенно в случаях распределенных систем обработки данных, когда пользователи, осуществляющие ввод информации в базу данных, не являются сотрудниками организации, осуществляющей свод отчетности и принимающей в соответствии с консолидированными данными определенные решения. В частности, такая структура характерна и для нашего случая. В том числе остается открытым вопрос о юридической ответственности за неверный ввод данных или намеренный ввод данных, не соответствующих действительности. Равно как и ответственность за действия, направленные на изменения информации с целью ввода в заблуждение органов, контролирующих свод и обработку данных, либо в целях дискредитации руководства нижестоящих организаций путем незаконного завладения идентификационными данными пользователя в системе. Долгое время, а именно с 2002 г., с принятием закона – Федеральный закон от 10 января 2002 г. N 1-ФЗ “Об электронной цифровой подписи” – в вопросах, описанных выше, не наблюдалось сколько-либо значимых изменений. Основной причиной подобного застоя в этом направлении считается фактическая монополизация процесса выдачи электронной цифровой подписи компанией ООО «КРИПТО-ПРО». Однако ситуация в этом направлении развития информационных технологий может существенно измениться уже с 1 июля 2022 года, что обусловлено принятием Федерального закона от 06.04.2022 №63-Ф3 “Об электронной подписи”, которым вводится ряд новых возможностей, позволяющих разработчикам информационно-вычислительных систем

совершенствовать процессы, связанные с использованием ЭЦП, в том числе путем ее создания.

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

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

1. Должна быть осуществлена возможность использования электронной подписи в будущем;

2. Должен быть реализован механизм логирования пользователей в системе в соответствии с их идентификационными данными, к которым относятся:

а) логин;

б) пароль;

в) ip-адрес электронного средства, с которого осуществляется ввод или изменение информации;

б) электронная подпись (в случае необходимости предъявления данного требования потребителем в рамках Федерального закона от 06.04.2022 №63-Ф3 “Об электронной подписи”);

3. Механизм логирования должен позволять идентифицировать пользователя в случаях создания записи, её изменения или удаления;

4. Удаляемая пользователем информация не должна физически удаляться из базы данных, но должна быть скрыта и не участвовать в процессе обработки данных;

5. Необходимо при ведении лога фиксировать транзакционное время осуществления действий пользователей в системе;

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

Опираясь далее на сформулированные принципы разработки модуля авторизации пользователей и разграничения прав доступа к данным, был осуществлен анализ разрабатываемого проекта на предмет практической реализации заявленной функциональности. Оказалось, что используемые нами подходы в части достижения кросс-платформенности, реализованные на основе Java Persistence API (JPA), не позволяют использовать типовые реализации журнализации транзакций, встроенные в современные СУБД. То есть для системы управления базами данных, все действия осуществляются одним пользователем, которому назначены соответствующие права доступа. При предложенной архитектуре информационной системы, представленной на рисунке 1, права доступа к данным и принципы логирования действий пользователей должны закладываться не на уровне базы данных, а на уровне DAO (data access object) слоя приложения.

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

1. Создание в СУБД записей, хранящихся в зашифрованном виде и однозначно идентифицирующих пользователей системы.

2. Разработка классов, осуществляющих шифрование и дешифрование данных, обеспечивающих их сохранение, извлечение и изменение.

3. Организация доступа пользователей к данным в рамках сессий с возможностью идентификации пользователя, его 1р-адреса, принадлежности к определённой организации и назначение ему в соответствии с этими параметрами определенных прав доступа к данным в рамках групповой политики.

4. Осуществление записи информации в базу данных при выполнении действий, модифицирующих ее состояние.

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

Рисунок 1 – Упрощенное представление архитектуры информационно-вычислительной системы.

Похожее:  Настройка авторизации WiFi-пользователей по SMS

Эти классом стал SuperAbstractBean, собственно говоря, его название вытекает из объявления, так как при использовании JPA спецификатор Abstract задает компилятору информацию о том, что данный класс не имеет объектов, то есть нет необходимости сохранять данный класс в базе – он не является самостоятельной сущностью (entity). А аннотация Entity с параметром «mappedSuperclass = true» позволяет хранить информацию наследников данного класса в различных таблицах базы данных.

Ниже приведен исходный код данного класса (для сокращения были приведены только методы, имеющие непосредственное отношение к реализации ядра проекта. Переопределенный метод toString, а также методы get и set для каждого из полей были опущены.): @RooEntity (mappedSuperclass = true)

public abstract class SuperAbstractBean implements Serializable{ private static final long serialVersionUID = 1L;

@Id

@GeneratedValue(strategy = GenerationType. AUTO)

@Column(name = “id”) protected Long id;

@Version

@Column(name = “version”) private Integer version; private Long userCreateID; private String userCreateIP; private String userCreateESign;

@Temporal(T em poralT ype. TIMES TAMP)

@DateTimeFormat(style = “M-“) private Date userCreateTime; private Long userModifyID; private String userModifyIP; private String userModifyESign;

@Temporal(T em poralT ype. TIMES TAMP)

@DateTimeFormat(style = “M-“) private Date userModifyTime; private Long userDeleteID; private String userDeleteIP; private String userDeleteESign;

@Temporal(T em poralT ype. TIMES TAMP)

@DateTimeFormat(style = “M-“) private Date userDeleteTime;

@Value(“false”)

private Boolean falseDelete;

@Transactional public void persist() {

if (this.entityManager == null) this.entityManager = entityManager(); if (WebApplication.gef()!= null){

WebApplicationContext wc = ((WebApplicationContext) WebApplication.gef().getContext());

setUserCreateID(WebApplication.gef().getUser().getId());

setUserCreateIP(wc.getBrowser().getAddress()); setUserCreateESign(WebApplication.get().getUser().getESign()); setUserCreateTime(new Date());

}

this.entityManager.persist(this);

}

@Transactional public void remove() {

if (WebApplication.get()!= null) {

WebApplicationContext wc = ((WebApplicationContext) WebApplication.get().getContext());

if (this.entityManager == null) this.entityManager = entityManager(); if (this.entityManager.contains(this)) { this.setUserDeleteID(WebApplication.gef().getUser().getId()); this.setUserDeleteIP(wc.getBrowser().getAddress()); this.setUserDeleteESign(WebApplication.gef().getUser().getESign());

this.setUserDeleteTime(new Date()); this.falseDelete = true;

} else {

SuperAbstractBean attached = findSuperAbstractBean(this.id); this.setUserDeleteID(WebApplication.gef().getUser().getId()); this.setUserDeleteIP(wc.getBrowser().getAddress()); this.setUserDeleteTime(new Date()); this.falseDelete = true;

}

}

else {

if (this.entityManager == null) this.entityManager =

entityManager();

if (this.entityManager.contains(this)) { this.entityManager.remove(this);

} else {

SuperAbstractBean attached = SuperAbstractBean.findSuperAbstractBean(this.id);

this.entityManager.remove(attached);

}

}

}

@Transactional

public SuperAbstractBean merge() { if (WebApplication.get()!= null) {

WebApplicationContext wc = ((WebApplicationContext) WebApplication.get().getContext());

if (this.entityManager == null) this.entityManager = entityManager(); this.setUserModifyID(WebApplication.gef().getUser().getId()); this.setUserModifyIP(wc.getBrowser().getAddress()); this.setUserDeleteESign(WebApplication.gef().getUser().getESign()); this.setUserModifyTime(new Date());

SuperAbstractBean merged = this.entityManager.merge(this);

this.entityManager.flush(); return merged;

}

else {

if (this.entityManager == null) this.entityManager = entityManager();

SuperAbstractBean merged = this.entityManager.merge(this); this.entityManager.flush(); return merged;

}

}

}

Почему для нас так важен именно этот класс? Да потому что он и составляет основную часть ядра модуля авторизации пользователей и разграничения прав доступа к данным. В нем инкапсулируются все методы, отвечающие сформулированным принципам для данного модуля. Наложением условий ограничения на разработку таким образом, что все классы, имеющие методы, осуществляющие любые вызовы DML (data manipulation language) операторов, должны наследоваться от SuperAbstractBean, мы гарантируем реализацию следующих сформулированных принципов:

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

2. Возможность использования электронной подписи.

3. Удаляемая пользователем информация физически не удаляется из базы данных, но может быть легко скрыта и не участвовать в процессе обработки данных (за это отвечает поле falseDelete, по умолчанию «false», что достигается использованием аннотации @Value(“false”).

4. При ведении лога фиксируется транзакционное время осуществления действий пользователей в системе.

Как видно из приведённого материала, была достигнута основная часть декларируемых показателей разрабатываемого модуля.

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

@PrePersist public void setNextId() { if (this. id == null) {

Identifier i = new Identifier();

if (this.getClass().getSimpleName().equals(“Region”) || this.getClass().getSimpleName().equals(“Rayon”)

|| this.getClass().getSimpleName().equals(“Company”)) { i.sqlCallfromDual(“Unit”);

} else {

i.sqlCallfromDual(this.getClass().getSimpleName());

}

setId(i.getNextID());

}

System.oa/.println(” private void prePers() = ” this.getClass().getSimpleName());

}

В дальнейшем предполагается полностью автоматизировать этот процесс путем внесения изменений в настроечном файле.

Что касается разработки механизма шифрования паролей, нашей командой было принято решение использовать библиотеку security из пакета org.springframework. Одним из основных классов данной библиотеки, отвечающих за шифрование и дешифрование данных, является MessageDigestPasswordEncoder. Для увеличения стойкости пароля к дешифрованию было использовано так называемое «подсаливание» ( salt). Для получения соли проводилась генерация UUID (Universally Unique identifier), затем выбиралась строка из 10 первых символов, после чего эти данные вместе с паролем передавались в качестве параметров методу encodePassword класса

SimplePasswordEncoder.

public void setPassword(String password) { if (!password.equals(this.password)) {

String salt = UUID.randomUUID().toString().substring(0, 10); this.salt = salt;

SimplePasswordEncoder pass = new SimplePasswordEncoder(“MD5”);

this.password = pass.encodePassword(password, salt);

}

}

public class SimplePasswordEncoder extends MessageDigestPasswordEncoder {

public SimplePasswordEncoder(String algorithm) { super(algorithm);

}

@Override

public String encodePassword(String originalPassword, Object salt) {

String encryptedPassword = super.encodePassword(originalPassword, salt); return encryptedPassword;

}

}

Как видно из исходного кода класса SuperAbstractBean, в проекте были использованы Spring – аннотации, а именно, для контроля механизма транзакций была использована аннотация Transactional, что позволило сократить количество исходного кода, увеличить его надежность и удобочитаемость. Для интеграции возможности

использования аннотаций в проекте был использован конфигурационный файл applicationContext.xml

Интеграция происходила путем внедрения зависимостей (Injection) в проект, ниже приводится пример конфигурационного файла:

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”no”?>

<beans xmlns=”http://www. springframework.org/schema/beans” xmlns:aop=”http://www.springframework.org/schema/aop” xmlns:context= “http://www. springframework.org/schema/context” xmlns:jee=”http://www.springframe work.org/schema/je e”

xmlns:tx=”http://www.springframework.org/schema/tx” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd

http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3. O.xsd http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-3.0.xsd

http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-3.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schemaftx/spring-tx-3.0.xsd'”>

<context:property-placeholder location=”classpath*:META-INF/spring/*.properties”/> <context:spring-configured/>

<context:component-scan base-package=”ru.sniizhk.f24a”>

<context:exclude-filter expression=”org.springframework.stereotype.Controller” type=”annotation”/> </context:component-scan>

<bean class=”org.apache.commons.dbcp.BasicDataSource” destroy-method=”close” id=”dataSource”> <property name=”driverClassName” value=”${database.driverClassName}”/>

<property name=”url” value=”${database.url}”/>

<property name=”username” value=”${database.username}”/>

<property name=”password” value=”${database.password}”/>

<property name=”testOnBorrow” value=”true”/>

<property name=”testOnReturn” value=”true”/>

<property name=”testWhileIdle” value=”true”/>

<property name=”timeBetweenEvictionRunsMillis” value=”1800000″/>

<property name=”numTestsPerEvictionRun” value=”3″/>

<property name=”minEvictableIdleTimeMillis” value=”1800000″/>

<property name=”validationQuery” value= “SELECT 1″/>

</bean>

<bean class=”org.springframework.orm.jpa.JpaTransactionManager” id=”transactionManager”>

<property name=”entityManagerFactory” ref= “entityManagerFactory”/>

</bean>

<tx:annotation-driven mode= “aspectj” transaction-manager= “transactionManager”/>

<bean class=”org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean” id=”entityManagerFactory”>

<property name=”persistenceUnitName” value= “persistenceUnit”/>

<property name=”dataSource” ref=”dataSource”/>

</bean>

</beans>

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

С помощью применения предложенной конфигурации стало возможным разделить настроечный файл на два отдельных. А именно, persistence.xml, отвечающий за инициализацию JPA, и database.properties, позволяющий изменять параметры доступа к базе

данных. Данные манипуляции позволили производить быструю смену иРА-провайдера, а также смену СУБД.

Для организации процесса разграничений прав доступа к данным в разрезе районов была осуществлена выборка данных по Ю авторизированно пользователя. На рисунках 2-4 показаны примеры входа в систему под авторизированными аккаунтами пользователей, осуществляющими ввод данных в рамках различных районов Ставропольского края. Для улучшения пользовательского интерфейса

при входе показывается герб района.

Рисунок 2 – Вход в систему под идентификационными данными пользователя, имеющего доступ к информации в пределах

Александровского района Ставропольского края.

Рисунок 3 – Вход в систему под идентификационными данными пользователя, имеющего доступ к информации в пределах Шпаковского района Ставропольского края.

1 СЗ @ ^-1

«- С 1 D Iocalhost:8090/f24a/ * =

SF MySQL Stored Funct… Новости науки И| Red Hat Linux 12 f MySQL database on … ¡с] 15 Practical Usages… Д Tomcat – ArchWiki Q ‘/ Статья: “MySQL. Ие… Birt Щ Creating and using r… »

Поголовье Воспроизводство Продуктивность Осеменение животных Забой Падеж Производство продукции (реализация) Производство продукции (выращивание)

Благодарненский район

Рисунок 4 – Вход в систему под идентификационными данными пользователя, имеющего доступ к информации в пределах Благодарненского района Ставропольского края.

При общении с потенциальным заказчиком была установлена необходимость ведения классификатора предприятий, осуществляющих свою деятельность на определенном отрезке времени. На рисунке 5 представлена форма редактирования классификатора предприятий в рамках роли «Аналитик». _________

f М Входящие (121) – suppor * J Iocalhost:8090/f24a/ Ж sql delete – Поиск в ( Зоо * Т g? S0L DELETE Statement х Т W Delete fSOLl —Википед! x [ ,=, | @ |^-£W|

4r C D Iocalhost:8090/f24a/ * s

SP MySQL Stored Funct… Q- Новости науки Red Hat Linux7.2 ^ MySQL database on .. . Q0 15 Practical Usages… Tomcat-ArchWiki Q V Статья: “MySQL Ие… Ä Birt Д Creating and using r„. »

Поголовье | Воспроизводство | Продуктивность Осеменение Забой Падеж Производство продукции (выращивание) Производство продукции (реализация) Компании

Добавить |“5 Изменить

НАИМЕНОВАНИЕ ИНН ОГРН ДАТА ОТКРЫТИЯ ДАТА ЗАКРЫТИЯ

▼ Ставропольский край

тАлександровский район Я

‘Колледж”

ЗАО МТС “Апексан-ское”

ОАО “Пятигоре. хУк”

ООО “Колос”

ООО “Надежда’

ООО ‘Русь’

ООО “Садовое”

ООО “Северное”

ПНИ

СПК к-з “Копос”

СП К к-з им.”Войтика”

СП К к-з* С еверное”

СПКА ПКЗ “Ставр-ский”

Крестьянские (фермерские) хозяйства

Личные подсобные хозяйства

тАндроповский район

ООО’АПККуршава

ООО “Каскад”

ООО “Прогресс”

ООО СХП’ Дружба’

СПК (с-з)’Курсавский”

Крестьянские (фермерские) хозяйства

Личные подсобные хозяйства –

Рисунок 5 – Вход в систему под идентификационными данными пользователя, имеющего доступ к системе в рамках роли «Аналитик».

На рисунке 6 представлена форма управления пользователями, соответствующая правам «Администратора пользователей».

Рисунок 6 – Вход в систему под идентификационными данными пользователя, имеющего доступ к системе в рамках роли «Администратор пользователей».

Что касается расширения возможностей механизма логирования, предложенного ранее, было принято решение организации триггеров на основных редактируемых таблицах после событий insert и update. Однако использование триггера после события delete в нашем случае не потребовалось в связи с тем, что в соответствии с хорошим тоном программирования баз данных физическое удаление информации не происходит, она лишь скрывается и модифицируется.

Похожее:  топ порталов в форк плеере

Для хранения полного лога событий была создана отдельная таблица “log_dml”, скрипт которой представлен ниже:

CREATE TABLE ‘log_dml’ (

‘id’ BIGINT(20) NOT NULL,

‘id_record’ BIGINT(20) NOT NULL,

‘id_table’ VARCHAR(255) COLLATE utf8_general_ci NOT NULL,

‘false_delete’ BIT(1) DEFAULT NULL,

‘user_createid’ BIGINT(20) NOT NULL,

‘user_createip’ VARCHAR(255) COLLATE utf8_general_ci NOT NULL, ‘user_create_time’ DATETIME NOT NULL,

‘user_create_esign’ VARCHAR(7000) COLLATE utf8_general_ci DEFAULT NULL, ‘user_deleteid’ BIGINT(20) DEFAULT NULL,

‘user_deleteip’ VARCHAR(7000) COLLATE utf8_general_ci DEFAULT NULL, ‘user_delete_time’ DATETIME DEFAULT NULL,

‘user_delete_esign’ VARCHAR(3)COLLATE utf8_general_ci DEFAULT NULL, ‘user_modifyid’ BIGINT(20) DEFAULT NULL,

‘user_modifyip’ VARCHAR(255) COLLATE utf8_general_ci DEFAULT NULL, ‘user_modify_time’ DATETIME DEFAULT NULL,

user_ modify_esign’ VARCHAR(7000) COLLATE utf8_general_ci DEFAULT NULL, ‘version’ INTEGER(11) DEFAULT NULL

) ENGINE=InnoDB AUTO_INCREMENT=1 CHARACTER SET ‘utf8’ COLLATE

‘utf8_general_ci’;

ALTER TABLE ‘log_dml’ ADD PRIMARY KEY (‘id’);

ALTER TABLE ‘log_dml’ MODIFY COLUMN ‘id’ BIGINT(20) NOT NULL AUTO_INCREMENT.

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

Литература:

1. Абонеев, В.В. Методика оценки мясной продуктивности овец /В.В. Абонеев, Ю.Д. Квитко, И.И. Селькин и др. //Ставрополь, 2009. -34 с.

2. Абонеев, В.В. Стратегия развития овцеводства в Российской Федерации /В.В. Абонеев //Достижения науки и техники АПК. -2008.-№10. -С. 37-39.

3. Абонеев, В.В. Приемы и методы повышения конкурентоспособности товарного овцеводства /В.В. Абонеев, Л.Н. Скорых, Д.В. Абонеев //ГНУ СНИИЖК, Ставрополь. -2022. -337 с.

4. Абонеев, В.В. Перспективные направления селекции овец в условиях рыночной экономики /В.В.Абонеев, А.Н. Соколов //Овцы, козы, шерстяное дело. -2007. -№ 1. -С. 7-11.

5. Абонеев, В.В. Развитие тонкорунного овцеводства в России /В.В. Абонеев, В.В. Марченко, А.И. Суров, А.А. Пикалов, А.И. Ерохин, С.А. Карасев //Овцы. Козы. Шерстяное дело. – 2022. – № 2. – С. 6-13.

6. Василенко, В.Н. Племенная база овцеводства Ростовской области /В.Н.Василенко, Ю.А. Колосов //Зоотехния, 2002. -№8. -С.9-12.

7. Завгородняя, Г.В. Мясная продуктивность баранчиков разных генотипов и уровней кормления /Г.В. Завгородняя, Ю.Д. Квитко, И.И. Дмитрик, И.П. Будякова, И.Н. Шарко //Овцы. Козы. Шерстяное дело, 2022. -№2. -С.42-44.

8. Квитко, Ю.Д. Проблемы и новые подходы в организации производства баранины /Ю.Д. Квитко //Сборник научных трудов Ставропольского научно-исследовательского института животноводства и кормопроизводства. -2005. -Т.1.№2. -С. 3-7.

9. Квитко, Ю.Д. Мясная продуктивность и качество мяса молодняка овец разного происхождения /Ю.Д. Квитко, А.В. Скокова, С.Ф. Силкина //Овцы. Козы. Шерстяное дело. – 2022. -№ 2. -С. 39-41.

10. Ковалюк, Н. В. Молекулярно-биологические методы для оздоровления стад крупного рогатого скота от лейкоза //Ветеринария. -2008. -№2. -С. 22-26.

11. Ковалюк, Н.В. Методические рекомендации по использованию маркера BoLA DRB3 в селекционно-племенной работе с крупным рогатым скотом: Рекомендации СКНИИЖ. /Н.В.Ковалюк, В.Ф. Сацук //Краснодар, 2022. -24 с.

12. Ковалюк, Н.В. Использование генетического маркера BOLA-DRB3 для оптимизации селекционного процесса при скрещивании /Н.В.Ковалюк, В.Ф. Сацук //Молочное скотоводство.-2022.-№2.-С.10-12.

13. Ковалюк, Н.В. Современные методы диагностики лейкоза крупного рогатого скота /Н.В. Ковалюк, В.Ф. Сацук, Е.В. Мачульская //Вестник Кубани. -2007. -№ 1.

14. Колосов, Ю.А., Информационное сопровождение селекционного процесса в овцеводстве: учебное пособие /Ю.А.Колосов, А.И.Бараников,

В.Н.Василенко, Н.В. Михайлов //Изд-во Донского ГАУ, пос. Персиановский, 2022. -55 с.

15. Колосов, Ю.А. Продуктивность молодняка породы советский меринос и её помесей с эдильбаевскими баранами/Ю.А. Колосов, С.В. Шихов //Овцы, козы, шерстяное дело. -2006. -№ 3. -С.7-10.

16. Колосов, Ю.А. Модель организации селекционно-племенной работы в овцеводстве с применением метода зависимых уровней отбора /Ю.А. Колосов, И.В. Засемчук //Новочеркасск, 2008.-С.76.

17. Новопашина, С.И. Переваримость питательных веществ рациона молочными козами при разном уровне протеина /С.И. Новопашина, Ю.Д. Квитко, М.Ю. Санников, Е.И. Кизилова //Овцы. Козы. Шерстяное дело. -2022. – № 2. – С. 64-67.

18. Ольховская, Л. В. Иммуногенетический анализ в селекции коз /Л.В. Ольховская, Л.Н. Чижова и др. //Ставрополь. ВНИИОК. -2000. -С.3-11.

19. Тимошенко, Н.К. Состояние и перспективы развития первичной обработки шерсти /Н.К. Тимошенко //Овцы, козы, шерстяное дело. -2007. -№ 4. -С. 46-50.

20. Тимошенко Н.К. Рынок шерсти: состояние и тенденции развития. /Н.К. Тимошенко, В.В. Абонеев //Овцы, козы, шерстяное дело. -2022. -№

2. -С. 50.

21. Чижова, Л.Н. Биохимические тест-системы, генетические маркеры продуктивности, их использование в селекции овец /Л.Н. Чижова //Автореф. дисс…. д-ра с.-х. наук. -Ставрополь, 2004. -58 с.

22. Чижова, Л.Н. Методические рекомендации комплексной оценки крупного рогатого скота мясных пород по фенотипу и генотипу /Л.Н. Чижова и др. //Ставрополь, 2008. -52с.

Сервис выдачи токенов

Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.

Основные функции:

Создание геттеров (getters)

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

Добавьте следующие getters к объекту:

getters : {
  isLoggedIn: state => !!state.token,
  authStatus: state => state.status,
}

Создание действия vuex login

Действия Vuex используются для фиксации мутаций в хранилище Vuex. Создадим действие login, которое аутентифицирует пользователя на сервере и передает учетные данные пользователя в хранилище vuex. Откройте файл ./src/store.js и добавьте следующее к объекту действий:

Создание действия logout

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

Создание мутаторов (mutations)

Мутаторы используются для изменения состояния store Vuex. Давайте определим мутаторы, которые мы использовали в нашем приложении. В объект мутаторов добавьте следующее:

Создания действия vuex register

Как и действие login, действие register будет работать почти так же. В том же файле добавьте следующее в объект действия:

Сокрытие страницы за аутентификацией

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

Нам также нужен способ сказать, зарезервирована ли страница только для аутентифицированного пользователя или не прошедшего аутентификацию пользователя, одного или обоих. Это важные соображения, которых, к счастью, мы можем достичь с помощью vue-router.

Токен доступа

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

Токен личности

Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.

Токен обновления

Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.

Более подробно о составе токенов в разделе «структура токена».

Формат

Picture10

Заключение


Для удобства я создал nugget-package библиотечку, установить которую можно следующей коммандой:

Install-Package MvcCustomizableFormAuthentication

Репозиторий с проектом находится на

, там есть пример рабочего приложения.

Всем спасибо за уделённое время. Жду советов, критики, предложений.

P.S.

Незабываем о unit-тестировании.

Заключение первой части

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

Stay tuned.

Спойлер второй части

Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:

public void Configuration(IAppBuilder app)
{
    var factory = new IdentityServerServiceFactory();
    factory.UseInMemoryClients(Clients.Get())
           .UseInMemoryScopes(Scopes.Get())
           .UseInMemoryUsers(Users.Get());

    var options = new IdentityServerOptions
    {
        SiteName = Constants.IdentityServerName,
        SigningCertificate = Certificate.Get(),
        Factory = factory,
    };

    app.UseIdentityServer(options);
}

Минимальная реализация интеграции веб-клиента с Identity Server:

public void Configuration(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = "Cookies"
    });

    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
    {
        ClientId = Constants.ClientName,
        Authority = Constants.IdentityServerAddress,
        RedirectUri = Constants.ClientReturnUrl,
        ResponseType = "id_token",
        Scope = "openid email",
        SignInAsAuthenticationType = "Cookies",
    });
}

Минимальная реализация интеграции веб-API с Identity Server:

public void Configuration(IAppBuilder app)
{
    app.UseIdentityServerBearerTokenAuthentication(
        new IdentityServerBearerTokenAuthenticationOptions
        {
            Authority = Constants.IdentityServerAddress,
            RequiredScopes = new[] { "write" },
            ValidationMode = ValidationMode.Local,

            // credentials for the introspection endpoint
            ClientId = "write",
            ClientSecret = "secret"
        });

    app.UseWebApi(WebApiConfig.Register());
}

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector