Abstract
In LOD, authentication is a key factor in the security dimension of linked data quality models. This is the case of (a) LMS that manages open educational resources (OERs), in training process, and (b) LMS integrated platforms, which also require authenticating users. Authentication tackles a range of problems such as users forgetting passwords and time consumption in repetitive logins in different applications. In the context of linked OERs that are developed in LMS, it is necessary to design guidelines in order to carry out the authentication process. This process authorizes access to different linked resources platforms. Therefore, to provide abstraction methods for this authentication process, it is proposed to work with model-driven architecture (MDA) approach. This paper proposes a security abstraction model on LMS, based on MDA. The proposed metamodel seeks to provide a set of guidelines on how to carry out unified authentication, establishing a common dialogue among stakeholders. Conclusion and future work are proposed in order to generate authentication instances that allow access to resources managed in different platforms.
1. Introduction
Model-driven engineering (MDE) [1–5] has as one of its first phases the search for the understanding of the problem to be addressed, that is, the knowledge of the problem domain. From this knowledge, an initial abstraction is constructed, using model schemes. These models are intended to be essential components for communication between the problem domain experts and software developers.
Based on the principle that the fundamental artifacts of development software are the models and not the programs, MDE proposes model-driven software development (MDD) based on the models that are generated from the most abstract to the most concrete through transformation or refinements steps, until arriving at the code applying a last transformation. Taking into account the above, the model-driven architecture (MDA), a concept promoted by object management group (OMG), is configured as an architecture that provides a set of guidelines to structure specifications expressed as models, following the MDD process [6]. On the other hand, linked open data (LOD) is a strategy to link open data licensed under one of the several open licenses that allow reuse [7]. In order to verify the linkage process, in addition to carry out different studies about the status of the data web [8–12], different linked data quality models have been proposed in LOD. These models define a dimensions and metrics set, such as those proposed by Zaveri et al. [13]. Within these dimensions, security has been considered, as a measure in which data access can be restricted and, therefore, protected against its alteration and misuse.
The security priority level depends on whether the data should be protected and whether there is a cost to the data that is unwittingly available. It should be noted that, although in the case of open data, the security aspect is often not very developed given that the data are freely accessible under a specific license. However, today’s students want to access the training at their own time rhythm and place, which has motivated them to implement LMS to join students’ personalized needs who seek an online learning with resources in mobile and dynamic environments. For this reason, LMS platforms, and their integration with other applications, pose a security challenge in aspects such as (a) user authentication, which consumes linked resources in these applications; (b) the management and remembrance of multiple users and passwords; (c) continuous calls to reset passwords; (d) time consumption by continuous logins in different platforms; and (e) managing different authentication schemes according to the platforms or applications used, among other factors [14, 15]. With the purpose of analyzing and establishing criteria about the integration of security as a quality dimension in the linked open educational resources, the question arises about How to structure a metamodel that provides an authentication abstraction process for linked open educational resources, supported on linked data quality dimensions? To address this research question, the use of MDA is proposed, in order to design a metamodel, which allows the generation of authentication instances for the linked open educational resources, supported by quality dimensions.
In Section 2, the background about the research subject is described. Subsequently, the methodological approach is presented in Section 3. The methodological development used for the metamodel approach is described in Section 4. In section 5, the results obtained and the discussion about them are exposed. Conclusion and future work are presented in Section 6.
2. Related Work
The main references that support the theoretical foundations used in this research are described below.
2.1. Identification and Authentication
As described in [16–18], when a user connects to a computer system, he/she must provide(i)User name or identification: identification is the ability to identify a user of a system or an application that is running in the system [19](ii)Password or authentication
Authentication is the ability to demonstrate that a user or an application is really who the said person or application claims to be [19]. To carry out this identity verification process, there are different proposals such as [17, 20, 21](i)Something that is known (e.g., password): the most basic authentication model is to decide if a user proves he is who he says he is. In this case, it is possible to use a knowledge test that only that user can answer.(ii)Something you have (e.g., badge, token, and smart card): an example of these are smart cards, which have a chip embedded in the card itself that can implement an encrypted file system and cryptographic functions and can also detect actively invalid attempts to access stored information.(iii)Something that one is (e.g., fingerprint, DNA, and iris): for example, the so-called biometric systems based on the physical characteristics of the user to be identified.(iv)Where you are (e.g., using a particular terminal).
To carry out authentication, the steps of (a) obtaining the authentication information of an entity, (b) analyzing the data, and (c) determining whether the authentication information is effectively associated with the entity are carried out [16]. For this process, there are authentication mechanisms such as passwords, challenge-response, alternative mechanisms (information, tags, cards, biometrics, signatures, etc.), and multiple methods, among others [22].
2.2. Linked Data Quality
As discussed in [23], published data may suffer from different problems given the heterogeneity of the data source, such as redundancy, inconsistencies, or may be incomplete. Therefore, queries made by applications that consume LOD may be inaccurate, ambiguous, or unreliable. Different authors [24–28] have proposed models and metrics to evaluate LOD instances published on the Web. Some of the criteria worked on in these proposals are oriented to provenance, content, RDF structure, and links, among other factors. It is important to note that in most of the references, a treatment of the proposed quality dimensions is identified, on the data instances already published on the Web.
On the other hand, some of these authors emphasize that quality must not only operate in the resource construction but also in the metadata itself, in order to seek the interoperability of said resources [29]. For the work in this investigation, the model proposed by Zaveri et al. [30] is proposed as a fundamental basis. This model qualitatively analyzes 30 main approaches to quality assurance and 12 tools using a set of attributes. As a result of this review, data quality dimensions and metrics model in LOD are proposed by the authors. Dimensions of (a) accessibility, (b) representation, (c) contextual, (d) intrinsic, (e) trust, and (f) dataset dynamicity are identified in this model.
2.3. MDE-MDA
MDE is a software development approach focused on the model generation to describe the elements of a system. Its main objective is the separation of the system design both from the architecture and from the construction technologies, facilitating that design and architecture can be modified independently. In this section, it is important to present some essential concepts in MDE [31–36]:(i)Meta-metamodel describes the proposed metamodels, generating a supremely high degree of abstraction in which all models coincide.(ii)Metamodel is a general structure in which entities are managed but not instances of them. The metamodel guides the model construction, through the description of the basic structure to follow, in addition to showing the interaction rules between defined entities. In summary, they are tools (rules, restrictions, models, and theories) that allow the model construction.(iii)Model is the application of the metamodel in a particular case, in other words, a structure in which general entities are not managed, but rather with specific instances of them. In general, it is a description (simplified representation) of one or more domain elements or real world.
As for MDA, this architecture provides a set of guidelines for structuring specifications expressed as models [5]. MDA focuses on the following three principles:(i)Direct representation focuses on the ideas and concepts of the problem domain and decreases the distance between the domain semantics and its representation, applies principles of abstraction, and separates relevant aspects from the problem domain of technology decisions(ii)Automation promotes the use of functionalities such as the exchange of models, the management of metamodels, the verification of consistency, and the transformation of models(iii)The use of open standards: the purpose is to achieve the interoperability in different tools and platforms, promoting the applications development
Metamodels in the context of MDA are expressed using meta-object facility (MOF), which proposes a 4-layer scheme: M0 (instances), M1 (the model), M2 (the metamodel), which define the elements of the model, and M3 (the meta-metamodel), which defines concepts, attributes, and relationships for the elements. Now, MDA adds to the model-driven approach the inclusion of several levels of abstraction (CIM, computation independent model; PIM, platform independent model; PSM, platform specific model) and several transformations between levels, thus carrying out system descriptions to several levels [2, 4, 35]. The development steps proposed in MDA are as follows [6]:(a)The system requirements are presented in a CIM model, which describes the situation in which the system will be used(b)The CIM model is transformed into a PIM model that describes the system, but does not show the details of its use in a particular technological platform(c)After obtaining the PIM model, another transformation is made to the PSM model, which contains the necessary detail to use the technological platform in which the system will operate(d)Finally, having the PSM model, a transformation is performed which results in the generation of code to achieve a solution or executable model
3. Methodological Approach
This research works on a quasiexperimental methodology. This design, as an empirical method, allows the analysis of the properties resulting from the application of the technological process, to obtain an analysis of the proposed variables. Considering that metamodels in the context of MDA are expressed in a 4-layer scheme, for this research process, M0: the instances; M1: the model; and M2: the metamodel layers are considered. From this perspective, the need to carry out a quasiexperimental design was proposed, in order to conceptually consider the abstraction process of the security dimension in the context of linked open educational resources, based on metamodels. This methodology is shown in Figure 1.
To develop this proposal, a methodological design structured in phases was defined, which allows to determine the processes that led to this research. In order to carry out the proposed design, the following phases are described succinctly:(a)Context approach: in this phase, in order to identify the theoretical elements of the research, the following question was designed to guide the research process: How to structure a metamodel that provides an authentication abstraction process for the linked open educational resources, supported on linked data quality dimensions? Based on the design of a metamodel for the abstraction of the authentication process for the linked open educational resources, it is important to take into account aspects of model-driven engineering and linked data quality, as key elements for the metamodel design, which allows generating guidelines for the construction of this abstraction.(b)LMS authentication: in this phase, the research problem and the strategies identification used for the authentication in LMS are proposed, as the main axis in the abstraction process of the knowledge domain. In the same way, the key requirements are defined, to feed the build process of the proposed metamodel.(c)Metamodel layers definition: after the requirements definition, the identification of the proposed layers for the elaboration of the conceptual design that will guide the metamodel implementation is carried out.(d)Verification example design: in this phase, the verification example is carried out that will show the follow-up to the conceptual design that will guide the metamodel implementation.(e)Results analysis: with the abstraction of the protocol to be followed and the corresponding application in the case of study, the proposed design is evaluated.
4. Methodological Development
4.1. LMS Authentication
In general, information is stored in an authentication process to carry out this process, such as user and password. As described in [37], in order to authenticate itself, a user generally provides at least two elements: (a) its identifier that allows its definition and (b) one or more elements that guarantee the authentication itself. Thus, independent of the mechanism, the same elements are found in different forms, for example,(i)Identifier and password.(ii)PKI certificates on smart card or USB token: identifier is a public certificate that is signed and consequently guaranteed by a recognized certification authority. The user must provide a secret element to be able to use the different cryptographic elements, for example, “PIN code of your card or your USB key.”(iii)Identifier and password on a smart card.(iv)Authentication by biometrics is based on the verification of an element of the user’s body (usually the fingerprint).(v)In multifactor authentication, different combinations such as smart card + PIN code, smart card + biometric, and biometric + password, among others, can be registered.
As for the learning management systems (LMSs), these are systems whose main function corresponds to providing sufficient support for the mediation of appropriation of knowledge and its administration, access to didactic and communication tools, and reuse of contents, among others. To carry out their objective, LMS must provide services and tools such as authentication. For such purpose, LMS must have an infrastructure to guarantee the users authentication [38]. In LMS such as Moodle, different authentication mechanisms through modules are developed, which allow easy integration with existing systems. Within these mechanisms are the following [39]:(i)Standard method of e-mail registration: students can create their own access accounts. The e-mail address is verified by confirmation.(ii)Lightweight Directory Access Protocol (LDAP) method: access accounts can be verified on an LDAP server. The administrator can specify which fields to use.(iii)Internet Message Access Protocol (IMAP), Post Office Protocol (POP3), and Network News Transport Protocol (NNTP): access accounts are verified against a mail or news server (news). Supports secure sockets layer (SSL) certificates and transport layer security (TLS).(iv)External database: any database, which contains at least two fields, can be used as an external authentication source.
An example of user authentication interfaces which access different applications of the District University (Academic Management and LMS) is shown in Figure 2. Each of them has an independent authentication mechanism.
4.2. Metamodel Layers Definition
According to the layer scheme defined for the metamodels in the MDA context, layers below were proposed to work on the framework project: (a) M0 (the authentication), (b) M1 (the authentication model), and (c) M2 (the metamodel). The structure of the meta-object facility (MOF) proposed for the project is shown in Figure 3. In this architecture, the following is proposed:(i)A metamodel that defines restrictions, rules, and theories set must be followed by the representations made about it. This layer will define requirements and restrictions, which must be met in any authentication process.(ii)A model that characterizes both the defined authentication strategy, supported on the quality dimension, and the requirements definition that these must meet in their design.(iii)A model instance, which represents the abstraction made of the knowledge domain, adjusted under metamodel constraints, in an own domain of linked data quality.
4.3. Verification Example Design
For the verification example design, the metamodel requirements must be identified in the first instance.
Case study: “A digital educational resources bank is connected to several institutional repositories. When a user enters the resource bank, after logging in, he should be able to access the different LMSs that manage the resources there related, even more so when said LMS corresponds to different providers. This single access provides the user with a username and password for each of the repositories, in order to access and consume the resources published there.”
For this problem context, metadata or data model requirements are not handled. The domains used correspond to security and LMS.
4.3.1. Knowledge Domain
The knowledge domain for the problem posed presents the following knowledge instances:(a)Quality Dimension. For this verification exercise, the security dimension was worked on, grouped in the accessibility category, based on the quality model proposed by Zaveri et al. [13]. According to the authors, this aspect describes the following:(i)Accessibility: the dimensions that belong to this category involve aspects related to the access and retrieval of data to obtain all or part of the data for a particular use case. There are five dimensions that are part of this group, which are availability, licensing, interconnection, security, and performance.(ii)Security: security is the metrics to which data access can be restricted and, therefore, protected against its alteration and misuse. Security is measured according to whether the data have an owner or require web security techniques (e.g., SSL or SSH) for accessing, acquiring, or reusing the data by users. The importance of security depends on whether the data should be protected and whether there is a cost of data that is unwittingly available. For open data, security is often not very developed since the data are freely accessible under a specific license.(b)Digital Repositories. As described in [41], a learning object repository (ROA) is a software system that stores educational resources and their metadata (or, only, the latter) and provides some type of resource search interface, either for interaction with humans or with other software systems. Additionally, there are learning management systems (LMSs), which allow designing courses based on the reuse and integration of learning objects. These resources have been searched and previously selected in repositories. Regarding authentication, an LMS must have an infrastructure to guarantee the authentication of its users.(c)Identification and Authentication. Identification is the ability to uniquely identify a system user or an application that is running on the system. Authentication is the ability to demonstrate that a user or an application is really who the said person or application claims to be [16].(d)Single Sign-On. It is an authentication mechanism [42], which allows users to access different systems through a single identification instance. In other words, single sign-on (SSO) is a concept to delegate the authentication of an end-user on a service provider (SP) to a third party, the so-called identity provider (IdP) [43]. The behavior proposed by single sign-on is shown in Figure 4.
In SSO, there are common configurations:(i)Enterprise single sign-on (E-SSO): It operates as a primary authentication and intercepts the login requirements that are required by the secondary applications in order to complete the user and password fields. For the correct operation of E-SSO, it is necessary that the underlying applications allow to disable the login interface.(ii)Web-based single sign-on (Web-SSO): this type of solution operates only with applications and resources that are accessed through the web. The access data are intercepted through a proxy, a component on the server, or the portion of software running on the client. Users, who have not been authenticated yet, are redirected to an authentication service from which they must return with a token or successful access.(iii)Kerberos: users register on a server and obtain a ticket (TGT: ticket-granting ticket), which is used by client applications to gain access.(iv)Federated identity: it corresponds to an identity management solution or identity management, which allows using the credentials available in one authentication system in others, either from the same organization or even from other companies. The above is done with standards that define mechanisms to share information between domains.
After a review, different SSO implementations were identified. These related works are shown below:(i)Web-SSO is a used technique to allow users to easily register and sign-in to websites with the use of social media accounts. These websites can be associated with new applications downloaded from Apple’s App Store, Android’s Google Play store, or even accessing website accounts [45].(ii)In Austria, most public sector applications use an open-source identity provider called MOA-ID. However, due to the sectorial identity management, MOA-ID has not been single sign-on capable. A security architecture that enables single sign-on between different governmental applications using MOA-ID as identity provider while meeting the requirements for sectorial data privacy protection at the same time is presented in [46]. This research achieves this by transforming unique sectorial identifiers of users with the help of an additional trusted attribute provider.(iii)A system which wants to integrate information systems by using web services should provide a unified identity authentication single sign-on scheme for heterogeneous platforms. This research introduces the characteristics of Kerberos-based single sign-on and SAML-based single sign-on [47].(iv)Federated access control schemes such as SAML and OpenID for authentication or OAuth for authorization enable secure, cross-domain single sign-on for web and mobile applications regardless of where users are located or what device they are using to start the authentication or authorization flows. Using federated schemes allow users to avoid managing as many user names and passwords as services they want to interact with. Instead, they ask for a token at some kind of identity provider or verifier and all services participating in the federation trust these tokens to solve authentication and/or authorization [48].(v)OpenID Connect is the OAuth 2.0-based replacement for OpenID 2.0 (OpenID) and one of the most important single sign-on (SSO) protocols used for delegated authentication. It is used by companies like Amazon, Google, Microsoft, and PayPal [43].
5. Results and Discussion
5.1. Requirements
Identified requirements are as follows:(i)Requirement R1 provides a security mechanism for accessing users and acquiring or reusing data.(ii)Requirement R2 provides an authentication mechanism that allows a user to access the LMS instances, where resources are managed.
5.2. Metamodel
Taking into account the above requirements, it is necessary to consider some situations described below, in order to build the metamodel:(a)Accessibility in a secure way to different LMSs, using the same access point, involves an authentication layer, which allows authenticating the access of consumers to exposed digital resources in each LMS.(b)In addition to the accessibility to different LMSs, it is possible to integrate the LMS with other tools, such as customer relationship management (CRM), electronic commerce, or any other application. This authentication scheme in different applications should also have a single authentication layer.
In other words, the task of this layer is twofold: on the one hand, integrating each authentication scheme from different LMSs, and on the other hand, offering an authentication service to users. Since each integrated LMS has its own authentication model, it is necessary to make an abstraction over multiple authentication models, unifying them under this basic metamodel. The proposed general metamodel is illustrated in Figure 5. The implementation of this authentication layer uses a metamodel that consists of the following three simple classes:(i)Entity. They are both the user who wishes to carry out the authentication and the authenticating entity, which handles the unified authentication mechanism and which can map the attributes to each LMS authentication scheme or integrated applications.(ii)Attribute. These factors are captured to carry out the identification (e.g., the nick) and the authentication (e.g., the token).(iii)Message. These are the request and response messages made between user and unified authentication system.
The restrictions that the metamodel handles are defined according to the unified authentication factors. As described in [24], different criteria can be configured, which can be taken as factors for authentication. An example of configuring basic criteria for IMAP is shown in Table 1.
According to the characteristics of the LMS authentication modules, the use of an identifier factor and an authenticating factor (pin, biometric, or a simple password) can be abstracted. To specify a little more, the requirements proposed by the domain abstraction, a more detailed metamodel where the entities, attributes, and messages are specified in textual form, are shown in Figure 6.
As seen in Figure 6, after receiving the message from the “User” entity, “Authenticator” entity processes the authentication of the factors submitted as attributes (credentials), generating a response message, either the authorization or the rejection of the user.
5.3. Model
To perform the interaction between entity, attribute, and message, the model design is proposed, which, in addition to responding to the criteria established in the metamodel, encapsulates access to identity management functions and provides a single session on. For this, delegator pattern in [51] is proposed, which allows an independent evolution of the weakly coupled identity management services while providing system availability. The class diagram, which visualizes the unique authentication model implementation based on a delegator pattern, is shown in Figure 7.
With this pattern implementation, the client does not interact directly with identity management service interfaces. The delegate prepares for the single session on, configures security session, looks for the physical security service interfaces, invokes the appropriate security service interfaces, and performs the global logout at the end [51].
5.4. Instances
The proposed model instance is based on single sign-on. An example of the login process in the TalentLms domain, through the SSO service, is shown in Figure 8.
Implementations of SSO in Canvas, WordPress, Atlassian, Jooomla, Drupal, and Magento, among other platforms, are described in [53, 54]. Research on SSO, which is being carried out at the Universidad Distrital Francisco José de Caldas, is shown in Figures 9 and 10. This proposal is based on The OAuth 2.0 Authorization Framework (RFC 6749) [55], a framework based on refresh tokens which are credentials used to obtain access tokens.
The developed interface is shown in Figure 11.
The aim of this research is to integrate academic applications, used at the Universidad Distrital. Subsequently, learning resources repositories will be integrated. For this integration, its metamodel proposes a set of recommendations. These recommendations will allow mapping generated tokens, to each learning objects repositories. This process lets perform respective authentication. In other words, for each authentication model, respectively, instantiated, the unified authentication mechanism will manage tokens for authentication process and according to their validity will allow access to the respective repository.
The proposed model focuses on user authentication and validation process that will allow them to access educational resources. Basic architecture for the credential verification process and after that access for query or management of educational resources is shown in Figure 12. Different points are shown in this model. Some of them are relationship between Web applications that share educational resources and messages passing to access control to resources. Access control is done by credentials, which are validated in SSO.
Token must be sent with each request that is made for queries or management of educational resources. When a request is made in the API manager, validation process starts, taking the token from the request header to query it in the authentication server and grant access permissions and consumption service in the API. By obtaining an educational resources list located in other applications, resource access will be transparent to users, since message flow for access authorization will be managed with the same implicit flow.
This model allows controlling access to educational resources on different applications that require credentials validation. In addition to manage permissions to repositories access, this model allows to edit resource information (if the application allows it). The flow is controlled and is supported through the most used authentication protocols, such as OAuth2.
As a discussion about what is the broad application of the SSO model beyond the case study proposed, a single authentication design has different advantages and disadvantages, which are exposed [39, 43, 45–48, 51, 58, 59]. Among the advantages, the following advantages are identified:(i)Minimizing the amount of passwords and usernames, which are used in password-based authentication for instance, and the ease in signing up for new websites and apps.(ii)With a single session record, factors such as the use and possible forgetting of multiple access keys are attacked, as well as reducing the time in different authentication processes.(iii)Using model implementation patterns, such as delegation, allows to improve the handling of the sessions, since the single sign-on service creates a secure SSO session and delegates the service requests to the relevant security services.(iv)By avoiding centralized management of users and authorizations, the applications themselves have to implement these mechanisms (it is delegated to the SSO itself), streamlining the process of provisioning user credentials for the different applications, and automating this process considerably reduces the error probability.(v)Multiplatform system allows the integration of different systems from different manufacturers in a single user authentication mechanism.
Disadvantages are as follows:(i)The SSO system accessing process allows an intruder to access all the systems covered by the SSO system. This inconvenience is usually mitigated by making the authentication process much stricter than in the usual processes.(ii)When SSO is implemented, it must be used very carefully. This is especially true if there is not complete control over who is authenticated by the identity provider. Authentication only provides information about the user’s identity; for this reason, it should be verified separately in each application what should be visible to him/her.
However, some contributions and findings were identified in the review as follows:(i)Using single sign-on delegator pattern, multiple instances of the remote security services will help improve scalability and support a standards-based single sign-on framework that does not require users to sign-on multiple times [51].(ii)The SSO process for web applications can use two techniques (a) using passive redirection mechanism: applications that are involved in the process do not communicate directly with each other, but rely on browser’s redirection and standard HTTP GET and POST messages. (b) Using “active SSO”: when a relying party application talks directly (e.g., via a Web Service) to the identity provider to validate the user’s identity and obtain the related security token [50].(iii)Under a corporate environment, the user needs to remember only one set of credentials to access various resources in and out of the organization’s network, in addition to increasing productivity by avoiding reentering your password to authenticate yourself in various resources repeatedly [52].(iv)Burden on the IT is cut down due to fewer helpdesk requests for password resets. Centralized authentication center and identity management allows quicker and better control over the accesses granted to each user [53].(v)SSO can be mixed with any of authentication methods (e.g., security questions, mobile authentication, and voice authentication) to augment your password-based authentication [54].
Finally, regarding the management of educational resources, which are stored in repositories with access control, SSO implementation guarantees access to these resources, performing a validation process of credentials from a centralized node. In this node, each one of the LMS that wants to query resources is registered. In this registration process, each application requests credentials validation to carry out access to resources. When a user wants to query a resource in a repository (which has valid credentials), one of the following scenarios could happen:(a)User is logged in into the centralized authentication node: if the user has previously accessed the centralized authentication module, this user will have access credentials for all those applications or repositories registered in the centralized node, so that credentials validation would be transparent to the user, allowing him/her to access to the educational resource.(b)User is not logged in, but if he/she is registered in centralized authentication node: when user tries to query the educational resource, a credential restriction will not allow him/her to query this resource, unless he/she accesses the application from the centralized node or from the application itself.(c)User is neither logged nor registered: this case is similar to the previous one; therefore, the process will be the same. Additionally, an option to register and query the educational resources will be offered by the centralized node.
In a nutshell, metamodel design for the security dimension abstraction, and specifically different LMS and authentication of integrated applications, is configured as a strategy, which provides an authentication unifying model. This model provides users with a single set of authenticating factors, which authorize applications under them authenticated. However, task of integrating each authentication scheme from different LMSs, where each one handles its own authentication model, is configured as restriction basis that metamodel must carefully manage, so that entities, attributes, and messages exposed perform corresponding mapping to each of the authentication instances. Derived from this, use of design patterns becomes a priority strategy when designing models.
Briefly, abstraction level offered by MDA becomes a useful tool when planning authentication scenarios, not only for access and authorization in LMS, but in different environments where applications are integrated and required to simplify user identification and authentication process.
6. Conclusion and Future Works
MDA, besides raising different abstraction levels, which are represented in models, allows the automatic code generation using built models. For this purpose, MDA makes use of metamodels, which correspond to a set of domain concepts to be modeled and the existing relationships between them, defined in an abstract way. The metamodels allow carrying out a better abstraction of the knowledge domain, through the identification of concepts, rules, restrictions, etc., which operate in the domain, facilitating their understanding.
Regarding the main aspects to be taken into account for the authentication metamodel definition for accessing the LMS, and the use of linked open educational resources, for the model back-end, the metamodel should consider (1) the identification and characterization of the authentication schemes from the different applications that are to be integrated and (2) the authentication factors identification and the mechanisms used to carry out this task. These elements provide relevant criteria and restrictions that are raised in the metamodel. These criteria are implemented in the design of the proposed model, through (a) entities that participate in the authentication process, (b) attributes or authentication factors which are mapped to different schemes, and (c) messages which are sent and received among different entities that participate in model instances.
Regarding the model's front-end, the metamodel must consider the parameterization of restrictions on authentication factors, which are requested from the user. Using this parameterization process, the factors can meet all necessary requirements in order to be mapped, by the integrated authentication unit, with each application authentication scheme, which are integrated into the model.
In the authentication metamodel, the linked educational resources taxonomy, or the metadata provided, is not considered relevant, since at this level what is sought is to provide an access and authorization mechanism to the platforms that manage those resources. In the generation of model instances, considerations such as the following should be taken into account:(i)With a single authentication point, authentication factors that authorize access and use of resources in different platforms are provided, according to the defined profiles. Therefore, the use of stronger authentication mechanisms should be considered, such as the use of multifactor authentication methods, which prevent unauthorized users from accessing information and resources that only have a password as an authentication factor.(ii)In the authentication process, only information about the user's identity is provided. Authorizations about what is visible to each user should be verified separately in each application.
Taking into account the above, the use of metamodels for the authentication abstraction is configured as a strategy of the knowledge domain representation, which will allow to define restrictions and necessary components so that an administrator can add new authentication mechanisms, in addition to providing new applications to the model that implements these authentication mechanisms. Future works are proposed (a) to extend the metamodeling process to the other linked data quality dimensions, proposed in the framework research of this project; (b) to design a metamodel for the process of generating data models for linked open educational resources, based on linked data quality dimensions; and (c) to carry out the framework implementation, which allows verification of the proposed metamodel for the linked open educational resources; and finally, to develop a machine learning solution to measure the level of trust in different queried repositories, after validation of access credentials.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Disclosure
The current work has been developed within the doctoral research project framework on Linked Data at the Universidad Distrital Francisco José de Caldas. In the same way, Linked Data is also being worked as a research topic of the GIIRA Research Group.
Conflicts of Interest
The authors declare that they have no conflicts of interest.