统一用户及权限管理系统概要设计说明书docx.docx

上传人:b****5 文档编号:14439235 上传时间:2023-06-23 格式:DOCX 页数:17 大小:58.60KB
下载 相关 举报
统一用户及权限管理系统概要设计说明书docx.docx_第1页
第1页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第2页
第2页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第3页
第3页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第4页
第4页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第5页
第5页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第6页
第6页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第7页
第7页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第8页
第8页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第9页
第9页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第10页
第10页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第11页
第11页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第12页
第12页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第13页
第13页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第14页
第14页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第15页
第15页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第16页
第16页 / 共17页
统一用户及权限管理系统概要设计说明书docx.docx_第17页
第17页 / 共17页
亲,该文档总共17页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

统一用户及权限管理系统概要设计说明书docx.docx

《统一用户及权限管理系统概要设计说明书docx.docx》由会员分享,可在线阅读,更多相关《统一用户及权限管理系统概要设计说明书docx.docx(17页珍藏版)》请在冰点文库上搜索。

统一用户及权限管理系统概要设计说明书docx.docx

统一用户及权限管理系统概要设计说明书docx

统一用户及权限管理系统

概要设计说明书

执笔人:

K1273-5班涂瑞

1.引言

1.1编写目的

在推进和发展电子政务建设的进程中,需要通过统一规划和设计,开发建设一套统一的授权管理和用户统一的身份管理及单点认证支撑平台。

利用此支撑平台可以实现用户一次登录、网内通用,避免多次登录到多个应用的情况。

此外,可以对区域内各信息应用系统的权限分配和权限变更进行有效的统一化管理,实现多层次统一授权,审计各种权限的使用情况,防止信息共享后的权限滥用,规范今后的应用系统的建设。

本文档旨在依据此构想为开发人员提出一个设计理念,解决在电子政务整合中遇到的一些问题。

1.2项目背景

随着信息化建设的推进,各区县的信息化水平正在不断提升。

截至目前,在各区县的信息化环境中已经建设了众多的应用系统并投入日常的办公使用,这些应用系统已经成为电子政务的重要组成部分。

各区县的信息体系中的现存应用系统是由不同的开发商在不同的时期采用不同的技术建设的,如:

邮件系统、政府内部办公系统、公文管理系统、呼叫系统、GIS系统等。

这些应用系统中,大多数都有自成一体的用户管理、授权及认证系统,同一用户在进入不同的应用系统时都需要使用属于该系统的不同账号去访问不同的应用系统,这种操作方式不仅为用户的使用带来许多不便,更重要的是降低了电子政务体系的可管理性和安全性。

与此同时,各区县正在不断建设新的应用系统,以进一步提高信息化的程度和电子政务的水平。

这些新建的应用系统也存在用户认证、管理和授权的问题。

1.3定义

1.3.1专门术语

数据字典:

对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述,其目的是对数据流程图中的各个元素做出详细的说明。

数据流图:

从数据传递和加工角度,以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程,是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

性能需求:

系统必须满足的定时约束或容量约束。

功能需求:

系统必须为任务提出者提供的服务。

接口需求:

应用系统与她的环境通信的格式。

约束:

在设计或实现应用系统时应遵守的限制条件,这些都只是说明用户或环境强加给项目的限制条件。

1.3.2缩写

SSO:

单点登录(SingleSignOn)

LDAP:

轻量目录访问协议(LightweightDirectoryAccessProtocol)

DSE:

目录服务代理条目(DSA-specificEntry)

ACL:

访问控制列表(AccessControlList)

JNDI:

(JavaNamingandDirectoryInterface)

CA:

即数字认证技术(CertificateAuthority)

SASL:

简单认证和安全通道(SimpleAuthenticationandSecureLayer)

PKI:

公钥基础设施(PublicKeyInfrastructure)

SSL:

安全套接字层(SecuritySocketLayer)

TLS:

传输安全通道(TransportLayerSecurity)

MD5:

信息-摘要算法(Message-DigestAlgorithm5)

DCE:

分布式计算环境(DistributedComputingEnvirionment)

UDDI:

统一描述、发现和集成协议(UniversalDescription,DiscoveryandIntegration)

1.4参考资料

1.软件工程张海藩清华大学出版社1990/11

2.软件工程及其应用周苏、王文等天津科学技术出版社1992/1

3.软件工程课程设计李龙澍机械工业出版社2010/4

2.任务概述

2.1目标

2.2运行环境

由于占用资源少,系统对运行环境的要求不高,理想的系统网络拓扑结构如图2.2.1所示:

2.2.1服务器

服务器可根据应用的规模选定,可采用各种专用的服务器系统或PC服务器系统(如;SUN服务器,IBM服务器,HP服务器等),使用操作系统可以为SUNSolaris或Linux。

2.2.2数据库软件

流行的大中型数据库软件,如Oracle、MSSQLServer、DB2、PostgreSQL、SYSBASE等。

2.2.3Web应用服务器

WebLogic6或以上版本

Websphere4或以上版本

JRun4或以上版本

Resin2.1.4或以上版本

Tomcat4或以上版本

2.2.4客户端

采用B/S结构的子系统运行于Web浏览器之上,硬件要求为Pentium133/32M以上配置。

2.3需求概述

系统提供统一的用户管理、身份认证及角色定制;一个全面的用户管理基础结构应该能够帮助公司实时地维持统一的用户特征,即便这些用户是为不同的应用系统而创建和使用。

统一的用户系统进行统一帐号创建、修改和删除,这使快速推出新的业务成为可能。

一个公司应该能拥有一个提供用户全面集中管理的管理层,而不为每个新的应用程序或服务建立分布的用户管理层。

各种电子政务应用的用户通过一个全局唯一的用户标示及存储于目录服务中的静态口令或由令牌获得动态口令,到认证服务器进行验证,如验证通过即可可登录到企业信息门户中访问集成的各种应用;可以在系统中维护用户信息并同步到各个应用中;能够根据其在企业的组织机构中的身份定制角色。

由于系统面向电子政务的各种应用,提供基于目录的统一用户权限管理及认证,故必须具备标准通用,安全稳定,响应快捷等特点的高性能服务能力。

2.4条件与限制

3.总体设计

3.1总体结构和模块外部设计

统一用户及权限管理系统的逻辑结构如下:

该系统采用VS.Net体系结构,采用C#编程语言,SqlServer2000数据库开发基于b/s结构的权限管理系统,该系统包括以下4个功能模块,每个模块又包含了几个到十几个不等的功能组,实现了权限管理所需的常用功能,其功能组成大致如下:

模块

功能组

登录页

登录页

用户授权管理

用户基本信息管理、用户包含的角色管理、用户包含的权限管理、用户组织机构管理、用户岗位管理

组织机构管理

组织机构基本信息管理、岗位基本信息管理、岗位包含的权限管理、岗位认证管理、拥有岗位的用户管理

应用权限定制

应用系统基本信息管理、应用系统权限组管理、应用系统权限管理、应用系统角色管理

系统维护

查询系统审计、查询应用审计

3.2功能分配

各项模块的功能可参照3.1中的说明。

客户机程序主要有三大块:

接收数据、网络通信及输出部分。

服务器程序主要也是由三大功能:

接收网络数据、数据库操作及发送网络数据部分。

服务器程序需与已建立的SQLSERVER数据库互连,其接口将于下面部分阐述。

3.3基于目录服务的系统设计

3.3.1目录服务简介

目录是一种特殊的数据库,目录服务就是按照树状信息组织模式,实现信息管理和服务接口的一种方法,目录服务是软件、硬件、策论以及管理的集合体;它服务于各种应用程序,包括LDAP(轻量级目录访问协议)目录和基于X.500的目录。

这些目录都是通用的标准的目录。

它们不适合于特定的操作系统、应用目的;目录服务系统一般由两部分组成:

第一部分是数据库,一种分布式的数据库,且拥有一个描述数据的规划;第二部分则是访问和处理数据库有关的详细的访问协议。

虽然目录也被称为特殊的数据库,但它不同于真正的数据库。

目录的大部分操作为读操作。

假如应用程序要写大量的数据,就应该考虑选择使用数据库来实现。

目录支持相对简单的事务处理。

与文件系统比较:

目录被认为是很差的文件系统。

文件通常很大,有几兆甚至更大,虽然目录被优化成存取很小的信息。

应用程序以块的方式存取文件。

文件系统支持各种调用--像seek(),read()和write(),这样可以写大文件的一部分的信息。

目录不能提供这种随机的存取访问。

目录条目被分成各种属性。

你可以分别获取各种属性。

你不能取得一个条目的部分值,如从第几个字节开始。

与web的比较:

不像web服务器一样,目录不适合推送JPEG图像或Java程序给客户端。

Web服务通常作为开发web应用的跳板。

这些平台从CGI(公用网关接口)到更复杂的像Netscape应用服务平台。

目录一般不提供这种形式的应用开发,甚至它不提供目录应用开发平台服务。

与FTP的主要区别在于:

数据量的大小和客户的类型。

另外一点就是FTP是一个非常简单的协议,它专于做一件事情并把它做好。

假如你想做的是把文件从一个地方传送到另一个地方,那么额外的目录下层结构也需要,如复制、查询、更新等。

与DNS比较:

因特网的域名系统和目录有相似之处,它们都提供对分层式数据库的访问。

但其它一些不同把它们区分开来。

DNS的主要目的是把主机名转换成IP地址。

比较而言,大多数目录有更普通的作用。

DNS有一套专门的、固定的计划,而目录允许被扩展。

DNS不允许更新它的信息,而目录可以。

DNS可通过UDP的无连接的方式访问,而目录通常是连接访问的。

目录服务与关系型数据库比较,目录不支持批量更新所需要的事务处理功能,目录一般只执行简单的更新操作,适合于进行大量数据的检索;目录具有广泛复制信息的能力,从而在缩短响应时间的同时,提高了可用性和可靠性。

目前,目录服务技术的国际标准有两个,即较早的X.500标准和近年迅速发展的LDAP标准。

X.500:

在八十年代中期,两个不同的团体--CCITT和ISO,各自开始在目录服务方面的研究工作。

最后,两个国际性的目录规范融合成一个规范,这就是X.500。

X.500的优势在于它的信息模型,它的多功能性和开放性。

LDAP:

1993年7月,第一个LDAP规范是由密歇根大学开发的,也就是RFC1487。

LDAP的开发者们简化了笨重的X.500目录访问协议,他们在功能性、数据表示、编码和传输方面做了改建。

目前,LDAP的版本是第3版本,相对以前版本来说,第3版本在国际化、提名、安全、扩展性和特性方面更加完善。

1997年,第3版本成为因特网标准。

由于LDAP所具有的查询效率高、树状的信息管理模式、分布式的部署框架以及灵活而细腻的访问控制,使LDAP广泛地应用于基础性、关键性信息的管理,如用户信息、网络资源信息等。

LDAP的应用主要涉及几种类型。

信息安全类:

数字证书管理、授权管理、单点登录;科学计算类:

DCE(DistributedComputingEnvirionment,分布式计算环境)、UDDI(UniversalDescription,DiscoveryandIntegration,统一描述、发现和集成协议);网络资源管理类:

MAIL系统、DNS系统、网络用户管理、电话号码簿;电子政务资源管理类:

内网组织信息服务、电子政务目录体系、人口基础库、法人基础库。

选择目录技术与否可参考以下几个方面信息:

*信息量大小。

目录适合于存放相对小的信息量,而不是几兆大小的文件;

*信息的类型。

目录通常是基于属性的信息;

*读写比。

目录适合于读操作更多的应用。

如需要用到大量的写操作,数据库是一个选择;

*搜寻能力。

目录能搜寻他自身包含的信息;

*标准访问。

假如你需要标准的访问信息,目录是一个好的选择;

3.3.2LDAP

LDAP(轻量级目录访问协议,LightweightDirectoryAccessProtocol)是实现提供被称为目录服务的信息服务。

目录服务是一种特殊的数据库系统,其专门针对读取,浏览和搜索操作进行了特定的优化。

目录一般用来包含描述性的,基于属性的信息并支持精细复杂的过滤能力。

目录一般不支持通用数据库针对大量更新操作操作需要的复杂的事务管理或回卷策略。

而目录服务的更新则一般都非常简单。

这种目录可以存储包括个人信息、web链结、jpeg图像等各种信息。

为了访问存储在目录中的信息,就需要使用运行在TCP/IP之上的访问协议—LDAP。

LDAP四种基本模型:

信息模型:

描述LDAP的信息表示方式。

在LDAP中信息以树状方式组织,在树状信息中的基本数据单元是条目,而每个条目由属性构成,属性中存储有属性值;LDAP中的信息模式,类似于面向对象的概念,在LDAP中每个条目必须属于某个或多个对象类(ObjectClass),每个ObjectClass由多个属性类型组成,每个属性类型有所对应的语法和匹配规则;对象类和属性类型的定义均可以使用继承的概念。

每个条目创建时,必须定义所属的对象类,必须提供对象类中的必选属性类型的属性值,在LDAP中一个属性类型可以对应多个值。

在LDAP中把对象类、属性类型、语法和匹配规则统称为Schema,在LDAP中有许多系统对象类、属性类型、语法和匹配规则,这些系统Schema在LDAP标准中进行了规定,同时不同的应用领域也定义了自己的Schema,同时用户在应用时,也可以根据需要自定义Schema。

这有些类似于XML,除了XML标准中的XML定义外,每个行业都有自己标准的DTD或DOM定义,用户也可以自扩展;也如同XML,在LDAP中也鼓励用户尽量使用标准的Schema,以增强信息的互联互通。

在Schema中最难理解的是匹配规则,这是LDAP中为了加快查询的速度,针对不同的数据类型,可以提供不同的匹配方法,如针对字符串类型的相等、模糊、大于小于均提供自己的匹配规则。

命名模型:

描述LDAP中的数据如何组织。

LDAP中的命名模型,也即LDAP中的条目定位方式。

在LDAP中每个条目均有自己的DN和RDN。

DN是该条目在整个树中的唯一名称标识,RDN是条目在父节点下的唯一名称标识,如同文件系统中,带路径的文件名就是DN,文件名就是RDN。

功能模型:

描述LDAP中的数据操作访问

在LDAP中共有四类10种操作:

查询类操作,如搜索、比较;更新类操作,如添加条目、删除条目、修改条目、修改条目名;认证类操作,如绑定、解绑定;其它操作,如放弃和扩展操作。

除了扩展操作,另外9种是LDAP的标准操作;扩展操作是LDAP中为了增加新的功能,提供的一种标准的扩展框架,当前已经成为LDAP标准的扩展操作,有修改密码和StartTLS扩展,在新的RFC标准和草案中正在增加一些新的扩展操作,不同的LDAP厂商也均定义了自己的扩展操作。

安全模型:

描述LDAP中的安全机制。

LDAP中的安全模型主要通过身份认证、安全通道和访问控制来实现。

身份认证在LDAP中提供三种认证机制,即匿名、基本认证和SASL(SimpleAuthenticationandSecureLayer)认证。

匿名认证即不对用户进行认证,该方法仅对完全公开的方式适用;基本认证均是通过用户名和密码进行身份识别,又分为简单密码和摘要密码认证;SASL认证即LDAP提供的在SSL和TLS安全通道基础上进行的身份认证,包括数字证书的认证。

通讯安全在LDAP中提供了基于SSL/TLS的通讯安全保障。

SSL/TLS是基于PKI信息安全技术,是目前Internet上广泛采用的安全服务。

LDAP通过StartTLS方式启动TLS服务,可以提供通讯中的数据保密性、完整性保护;通过强制客户端证书认证的TLS服务,同时可以实现对客户端身份和服务器端身份的双向验证。

访问控制虽然LDAP目前并无访问控制的标准,但从一些草案中或是事实上LDAP产品的访问控制情况,我们不难看出:

LDAP访问控制异常的灵活和丰富,在LDAP中是基于访问控制策略语句来实现访问控制的,这不同于现有的关系型数据库系统和应用系统,它是通过基于访问控制列表来实现的,无论是基于组模式或角色模式,都摆脱不了这种限制。

LDAP目录中的信息是按照树型结构组织,具体信息存储在条目(entry)的数据结构中。

条目相当于关系数据库中表的记录;条目是具有区别名DN(DistinguishedName)的属性(Attribute),DN是用来引用条目的,DN相当于关系数据库表中的关键字(PrimaryKey)。

属性由类型(Type)和一个或多个值(Values)组成,相当于关系数据库中的字段(Field)由字段名和数据类型组成,只是为了方便检索的需要,LDAP中的Type可以有多个Value,而不是关系数据库中为降低数据的冗余性要求实现的各个域必须是不相关的。

LDAP中条目的组织一般按照地理位置和组织关系进行组织,非常的直观。

LDAP把数据存放在文件中,为提高效率可以使用基于索引的文件数据库,而不是关系数据库。

类型的一个例子就是mail,其值将是一个电子邮件地址。

LDAP的信息是以树型结构存储的,在树根一般定义国家(c=CN)或域名(dc=com),在其下则往往定义一个或多个组织(organization)(o=Acme)或组织单元(organizationalunits)(ou=People)。

一个组织单元可能包含诸如所有雇员、大楼内的所有打印机等信息。

此外,LDAP支持对条目能够和必须支持哪些属性进行控制,这是有一个特殊的称为对象类别(objectClass)的属性来实现的。

该属性的值决定了该条目必须遵循的一些规则,其规定了该条目能够及至少应该包含哪些属性。

例如:

inetorgPerson对象类需要支持sn(surname)和cn(commonname)属性,但也可以包含可选的如邮件,电话号码等属性。

3.3.3SUNiPlanet

SUN的iPlanet电子商务解决方案中的统一用户管理工具能够适应用户管理基础结构的要求,

iPlanet统一用户管理套件提供了对电子商务企业中所使用的各个系统进行统一和集中用户管理功能,该套件包括以下几个部分:

目录服务器:

作为统一用户管理套件的核心,为企业中的多种应用统一保存雇员、合作伙伴及供应商的信息,为套件中的其它部件提供了可伸缩性、高性能和细致存取控制。

元目录服务:

给从其它应用系统增加的用户信息提供统一管理方式,包括加入引擎、连接器、帐号管理合并、用户帐号集成及消息系统集成等部件。

加入引擎使用一个高度灵活的并且可扩展的规则,决定怎样从不同的信息来源来联合用户数据。

这些规则能被用来控制数据更改的方向,为用户数据的不同类型定义来源,进行用户数据的管理。

连接器是一组软件模块,用来与特定的数据来源交换信息,并提供给加入引擎使用。

这些模块可以在不同的系统中配置和安装。

灵活的体系结构使公司可以细致地调整元目录服务,使之提供最好的性能和可伸缩性,便于快速开发网上应用。

帐号管理合并可以把多种来源信息集成帐号信息,包括顾客数据库、网络操作系统、邮件系统和电话交换机等。

这种集成使基于Web的应用程序统一掌握用户信息,便于新的增值应用的快速开发。

用户帐号集成可以自动完成用户帐号和相关信息的增加、改变和删除。

例如,当在一个系统中建立一个用户时,元目录服务能自动地在其它系统上产生用户的帐号信息,因此用户只须记住一个帐号,而且用户的信息被所有系统所了解,也便于不同的系统对所有用户进行定制的管理,而不论用户的信息来源如何。

消息系统集成可以使企业方便地与不同系统中的用户,如雇员、合作伙伴、供应商和客户之间建立联系。

证书管理系统:

为应用系统提供了根据适当的安全级别来认证用户的方法,便于在公共的网络上部署支持加密、认证、篡改检测和数字签名等应用。

数字证书作为身份的证明,可使用户在使用应用或服务时被赋予适当的存取权限。

证书管理系统包括3个独立的分系统,并具有高度灵活地安装和配置选择,允许一个公司基于已存在的策略定制它的PKI(公共密钥)部署。

证书管理器作为证书发出、更新和废除时使用的认证授权证书。

一个或多个注册管理器可以安装在防火墙外面用来代理证书的请求,可以被合作伙伴或供应商所使用。

当用户忘记口令或离开他们的工作时,数据恢复管理器保护加密的数据以免于丢失。

3.4安全认证

3.4.1系统的安全特性

(1)基于简单认证机制中的口令认证机制,以用户名和密码为确认用户身份的标志;

(2)在认证过程中,明文密码绝不能在网络上传输,防止窃听导致泄密,保证用户密码的安全;

(3)可以实现认证客户端和认证服务器的双向认证,确保认证双方的身份;

(4)能够抵抗重放攻击,既防止攻击者使用窃听到的过时的认证数据包再次获得认证而冒充合法用户的身份;

应用服务器既作为相对用户的服务器,又作为统一口令认证系统的客户端。

它们首先通过安全传输通道(如SSL通道)获取用户提交的用户名和密码,然后通过口令认证系统提供的统一口令认证模块经由安全认证通道向口令认证服务器提交认证请求,并获得认证结果(成功或失败),最终确定是否给该用户提供服务;并引用LDAP的ACL(AccessControlList)机制。

3.4.2认证算法

考虑到系统的安全和高效,要求设计的认证算法亦是安全、高效。

安全主要有三方面:

(1)在认证过程中传输的数据不怕被窃听,通过对传输的数据进行加密实现;

(2)传输中的数据可以防止被篡改,通过对传输的数据进行数字签名实现;

(3)可以抵抗重放攻击,方法是在认证数据包中打时戳,或在认证过程中使用Challenge-Response方法实现。

采用时戳需要各系统实现时间同步,增加了系统的不安全性,故一般实现多采用Challenge-Response方法。

借鉴radius的CHAP认证算法,提出下面的算法模型,其流程如下:

C:

Client,认证客户,一般为应用服务器;

S:

Server,统一口令认证服务器;

K:

C和S之间的共享秘密,即待认证用户的单向加密后的密码;

N:

待认证用户的用户名;

R:

S产生的随机数;

H{M}:

对消息M做单向Hash消息摘要运算,可使用MD5算法;

CK{M}:

以密钥K使用对称加密算法对消息M进行对称加密,可使用DES算法;

r:

认证的结果,成功或失败;

1.C=>S:

N,H{N+K+0}

2.S=>C:

CK{R},H{N+CK{R}+K+R}

3.C=>S:

N,CK{R,K},H{N+CK{R,K}+K+R}

4.S=>C:

CK{r,R},H{N+CK{r}+K+R}

在认证的每一个步骤中,无论客户端还是服务器端,都要求对数据包中的H{}域做校验。

由于H{}域中包含了C和S之间的共享秘密,所以对于不知道此秘密的攻击者而言,是无法伪造合法的数据包的,也由此双向证实了C或S的身份。

认证的过程分为预请求和正式请求两部分,其中预请求是C向S获取随机数R的过程,在正式的认证请求中C必须向S提交此凭据。

由于R对于每次认证请求都不同,且在S端有记录,攻击者即使窃听到了一个成功的认证请求包,在下次使用时却失效了,所以可以很好的防重放攻击。

 

3.5功能需求与程序的关系

功能需求的实现同各块程序的分配关系矩阵图:

功能需求/程序模块

目录服务维护

安全策略服务

系统用户中心

组织机构管理

用户角色定制

服务部署维护

系统

维护

SSO实现

用户新增/删除/修改

组织机构管理

角色定制

应用系统注册

应用接口

日志管理

应用协作管理

4.接口设计

4.1用户接口

应用管理接口;

应用部署接口;

功能扩展接口。

4.2外部接口

用户信息同步接口;

应用组织机构接口;

应用角色信息接口;

应用授权接口;

应用目录服务接口;

应用认证接

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 总结汇报 > 实习总结

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2