SAML2.0核心协议规范saml-core-2.0-os详解

需积分: 10 182 浏览量更新于2024-07-20 收藏 616KB PDF 举报

SAML2.0核心协议规范（saml-core-2.0-os）是OASIS（Organization for the Advancement of Structured Information Standards）于2005年3月15日发布的标准文档，全称为Security Assertion Markup Language (SAML) V2.0。该规范定义了SAML版本2.0中的assertions（声明）和协议，用于在安全上下文中交换身份验证、授权和审计等信息。 SAML（Security Assertion Markup Language）是一种基于XML的标准，旨在简化和标准化网络环境中不同安全系统的交互。SAML V2.0的核心目标是促进跨域身份管理，使得用户能在多个应用和服务之间进行无缝的身份验证，而无需多次登录或输入凭据。这个版本的规范特别关注身份提供商（IdP）、服务提供者（SP）以及可能的认证权威机构（AA）之间的通信。文档的主要部分包括： 1. Assertions：这部分详细阐述了SAML assertions的结构和内容，它是一个包含身份声明的数据结构，可以表示用户身份、权限或其他相关属性。assertions被设计成可以在不同系统间传递，以便验证用户的身份。 2. Protocols：规范涉及SAML的各种协议，如SAML 2.0 Artifact Resolution Protocol（ART）、Single Sign-On（SSO）、Single Logout（SLO）等，这些协议定义了如何在参与方之间安全地发送和接收assertions。 3. 编辑者与贡献者：文档由多位来自互联网2（Internet2）、诺基亚、RSA Security、Sun Microsystems等公司的专家共同编辑，他们代表了各个领域的技术公司和个人，确保了规范的广泛代表性和实用性。 4. 版权声明：OASIS Open保留所有权利，强调了该规范的专有性和使用规则。 SAML 2.0的核心协议规范saml-core-2.0-os是IT安全领域的一个关键组件，它对于实现现代Web服务的单点登录（SSO）、跨组织访问控制和身份验证至关重要。通过遵循这一标准，企业和组织能够构建安全的网络环境，提高用户体验并降低管理复杂性。要深入理解和实施SAML 2.0，开发人员和安全专业人员需要掌握其中的协议细节、消息格式、加密机制以及相关的安全策略配置。

</extension>

</simpleContent>

</complexType>

2.2.3 Element <NameID>

The <NameID> element is of type NameIDType (see Section 2.2.2), and is used in various SAML

assertion constructs such as the <Subject> and <SubjectConfirmation> elements, and in various

protocol messages (see Section 3).

The following schema fragment defines the <NameID> element:

2.2.4 Element <EncryptedID>

The <EncryptedID> element is of type EncryptedElementType, and carries the content of an

unencrypted identifier element in encrypted fashion, as defined by the XML Encryption Syntax and

Processing specification [XMLEnc]. The <EncryptedID> element contains the following elements:

<xenc:EncryptedData> [Required]

The encrypted content and associated encryption details, as defined by the XML Encryption

Syntax and Processing specification [XMLEnc]. The Type attribute SHOULD be present and, if

present, MUST contain a value of http://www.w3.org/2001/04/xmlenc#Element. The

encrypted content MUST contain an element that has a type of NameIDType or AssertionType,

or a type that is derived from BaseIDAbstractType, NameIDType, or AssertionType.

<xenc:EncryptedKey> [Zero or More]

Wrapped decryption keys, as defined by [XMLEnc]. Each wrapped key SHOULD include a

Recipient attribute that specifies the entity for whom the key has been encrypted. The value of

the Recipient attribute SHOULD be the URI identifier of a SAML system entity, as defined by

Section 8.3.6.

Encrypted identifiers are intended as a privacy protection mechanism when the plain-text value passes

through an intermediary. As such, the ciphertext MUST be unique to any given encryption operation. For

more on such issues, see [XMLEnc] Section 6.3.

Note that an entire assertion can be encrypted into this element and used as an identifier. In such a case,

the <Subject> element of the encrypted assertion supplies the "identifier" of the subject of the enclosing

assertion. Note also that if the identifying assertion is invalid, then so is the enclosing assertion.

The following schema fragment defines the <EncryptedID> element and its EncryptedElementType

complex type:

</sequence>

</complexType>

saml-core-2.0-os 15 March 2005

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

2.2.5 Element <Issuer>

The <Issuer> element, with complex type NameIDType, provides information about the issuer of a

SAML assertion or protocol message. The element requires the use of a string to carry the issuer's name,

but permits various pieces of descriptive data (see Section 2.2.2).

Overriding the usual rule for this element's type, if no Format value is provided with this element, then the

value urn:oasis:names:tc:SAML:2.0:nameid-format:entity is in effect (see Section 8.3.6).

The following schema fragment defines the <Issuer> element:

2.3 Assertions

The following sections define the SAML constructs that either contain assertion information or provide a

means to refer to an existing assertion.

2.3.1 Element <AssertionIDRef>

The <AssertionIDRef> element makes a reference to a SAML assertion by its unique identifier. The

specific authority who issued the assertion or from whom the assertion can be obtained is not specified as

part of the reference. See Section 3.3.1 for a protocol element that uses such a reference to ask for the

corresponding assertion.

The following schema fragment defines the <AssertionIDRef> element:

2.3.2 Element <AssertionURIRef>

The <AssertionURIRef> element makes a reference to a SAML assertion by URI reference. The URI

reference MAY be used to retrieve the corresponding assertion in a manner specific to the URI reference.

See Section 3.7 of the Bindings specification [SAMLBind] for information on how this element is used in a

protocol binding to accomplish this.

The following schema fragment defines the <AssertionURIRef> element:

2.3.3 Element <Assertion>

The <Assertion> element is of the AssertionType complex type. This type specifies the basic

information that is common to all assertions, including the following elements and attributes:

Version [Required]

The version of this assertion. The identifier for the version of SAML defined in this specification is

"2.0". SAML versioning is discussed in Section 4.

ID [Required]

The identifier for this assertion. It is of type xs:ID, and MUST follow the requirements specified in

Section 1.3.4 for identifier uniqueness.

IssueInstant [Required]

The time instant of issue in UTC, as described in Section 1.3.3.

saml-core-2.0-os 15 March 2005

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

556

557

<Issuer> [Required]

The SAML authority that is making the claim(s) in the assertion. The issuer SHOULD be unambiguous

to the intended relying parties.

This specification defines no particular relationship between the entity represented by this element

and the signer of the assertion (if any). Any such requirements imposed by a relying party that

consumes the assertion or by specific profiles are application-specific.

<ds:Signature> [Optional]

An XML Signature that protects the integrity of and authenticates the issuer of the assertion, as

described below and in Section 5.

<Subject> [Optional]

The subject of the statement(s) in the assertion.

<Conditions> [Optional]

Conditions that MUST be evaluated when assessing the validity of and/or when using the assertion.

See Section 2.5 for additional information on how to evaluate conditions.

<Advice> [Optional]

Additional information related to the assertion that assists processing in certain situations but which

MAY be ignored by applications that do not understand the advice or do not wish to make use of it.

Zero or more of the following statement elements:

A statement of a type defined in an extension schema. An xsi:type attribute MUST be used to

indicate the actual statement type.

An authentication statement.

An authorization decision statement.

An attribute statement.

An assertion with no statements MUST contain a <Subject> element. Such an assertion identifies a

principal in a manner which can be referenced or confirmed using SAML methods, but asserts no further

information associated with that principal.

Otherwise <Subject>, if present, identifies the subject of all of the statements in the assertion. If

<Subject> is omitted, then the statements in the assertion apply to a subject or subjects identified in an

application- or profile-specific manner. SAML itself defines no such statements, and an assertion without a

subject has no defined meaning in this specification.

Depending on the requirements of particular protocols or profiles, the issuer of a SAML assertion may

often need to be authenticated, and integrity protection may often be required. Authentication and

message integrity MAY be provided by mechanisms provided by a protocol binding in use during the

delivery of an assertion (see [SAMLBind]). The SAML assertion MAY be signed, which provides both

authentication of the issuer and integrity protection.

If such a signature is used, then the <ds:Signature> element MUST be present, and a relying party

MUST verify that the signature is valid (that is, that the assertion has not been tampered with) in

accordance with [XMLSig]. If it is invalid, then the relying party MUST NOT rely on the contents of the

assertion. If it is valid, then the relying party SHOULD evaluate the signature to determine the identity and

appropriateness of the issuer and may continue to process the assertion in accordance with this

saml-core-2.0-os 15 March 2005

558

559

560

561

562

563

564

565

566

567

568

569

570

571

572

573

574

575

576

577

578

579

580

581

582

583

584

585

586

587

588

589

590

591

592

593

594

595

596

597

598

599

600

601

specification and as it deems appropriate (for example, evaluating conditions, advice, following profile-

specific rules, and so on).

Note that whether signed or unsigned, the inclusion of multiple statements within a single assertion is

semantically equivalent to a set of assertions containing those statements individually (provided the

subject, conditions, etc. are also the same).

The following schema fragment defines the <Assertion> element and its AssertionType complex type:

</choice>

</sequence>

</complexType>

2.3.4 Element <EncryptedAssertion>

The <EncryptedAssertion> element represents an assertion in encrypted fashion, as defined by the

XML Encryption Syntax and Processing specification [XMLEnc]. The <EncryptedAssertion> element

contains the following elements:

<xenc:EncryptedData> [Required]

The encrypted content and associated encryption details, as defined by the XML Encryption

Syntax and Processing specification [XMLEnc]. The Type attribute SHOULD be present and, if

present, MUST contain a value of http://www.w3.org/2001/04/xmlenc#Element. The

encrypted content MUST contain an element that has a type of or derived from AssertionType.

<xenc:EncryptedKey> [Zero or More]

Wrapped decryption keys, as defined by [XMLEnc]. Each wrapped key SHOULD include a

Recipient attribute that specifies the entity for whom the key has been encrypted. The value of

the Recipient attribute SHOULD be the URI identifier of a SAML system entity as defined by

Section 8.3.6.

Encrypted assertions are intended as a confidentiality protection mechanism when the plain-text value

passes through an intermediary.

The following schema fragment defines the <EncryptedAssertion> element:

2.4 Subjects

This section defines the SAML constructs used to describe the subject of an assertion.

saml-core-2.0-os 15 March 2005

602

603

604

605

606

607

608

609

610

611

612

613

614

615

616

617

618

619

620

621

622

623

624

625

626

627

628

629

630

631

632

633

634

635

636

637

638

639

640

641

642

643

644

645

646

2.4.1 Element <Subject>

The optional <Subject> element specifies the principal that is the subject of all of the (zero or more)

statements in the assertion. It contains an identifier, a series of one or more subject confirmations, or

both:

<BaseID>, <NameID>, or <EncryptedID> [Optional]

Identifies the subject.

<SubjectConfirmation> [Zero or More]

Information that allows the subject to be confirmed. If more than one subject confirmation is provided,

then satisfying any one of them is sufficient to confirm the subject for the purpose of applying the

assertion.

A <Subject> element can contain both an identifier and zero or more subject confirmations which a

relying party can verify when processing an assertion. If any one of the included subject confirmations are

verified, the relying party MAY treat the entity presenting the assertion as one that the asserting party has

associated with the principal identified in the name identifier and associated with the statements in the

assertion. This attesting entity and the actual subject may or may not be the same entity.

If there are no subject confirmations included, then any relationship between the presenter of the assertion

and the actual subject is unspecified.

A <Subject> element SHOULD NOT identify more than one principal.

The following schema fragment defines the <Subject> element and its SubjectType complex type:

</choice>

<element ref="saml:SubjectConfirmation" minOccurs="0"

maxOccurs="unbounded"/>

</sequence>

</choice>

</complexType>

2.4.1.1 Element <SubjectConfirmation>

The <SubjectConfirmation> element provides the means for a relying party to verify the

correspondence of the subject of the assertion with the party with whom the relying party is

communicating. It contains the following attributes and elements:

Method [Required]

A URI reference that identifies a protocol or mechanism to be used to confirm the subject. URI

references identifying SAML-defined confirmation methods are currently defined in the SAML profiles

specification [SAMLProf]. Additional methods MAY be added by defining new URIs and profiles or by

private agreement.

<BaseID>, <NameID>, or <EncryptedID> [Optional]

Identifies the entity expected to satisfy the enclosing subject confirmation requirements.

saml-core-2.0-os 15 March 2005

647

648

649

650

651

652

653

654

655

656

657

658

659

660

661

662

663

664

665

666

667

668

669

670

671

672

673

674

675

676

677

678

679

680

681

682

683

684

685

686

687

688

689

690

691

剩余85页未读，继续阅读

lw2078

粉丝: 14
资源: 6

SAML2.0核心协议规范saml-core-2.0-os详解

SAML 2.0 详解

基于SAML 2.0 SSO单点登录

SAML2.0 简介

saml2.0idp参数配置

springboot 集成saml2.0

c# saml:2.0

java saml2.0

阿里云idaas saml2.0 SAMLResponse 如何解析

saml2.0 sp和idp 的证书配置，双向认证代码

springboot集成saml2.0 代码示例 包含IDP SP

最新资源

springboot集成saml2.0 代码示例包含IDP SP