다양한 상용 CA를 사용할 수 있습니다. 상용 CA를 사용하여 인증서에 서명하는 메커니즘은 선택한 CA에 따라 다릅니다.

상용 CA의 장점은 종종 많은 수의 사람이 신뢰할 수 있다는 것입니다. 조직 외부의 시스템에서 애플리케이션을 사용할 수 있도록 설계된 경우 상용 CA를 사용하여 인증서에 서명합니다. 애플리케이션이 내부 네트워크 내에서 사용할 경우 개인 CA가 적합할 수 있습니다.

상용 CA를 선택하기 전에 다음 기준을 고려하십시오.

시스템의 인증서에 서명해야 하는 경우 개인 CA를 설정합니다. 개인 CA를 설정하려면 인증서를 생성하고 서명하기 위한 유틸리티를 제공하는 소프트웨어 패키지에 액세스해야 합니다. 이 유형의 여러 패키지를 사용할 수 있습니다.

개인 CA를 설정할 수 있는 소프트웨어 패키지 중 하나는 OpenSSL, http://www.openssl.org 입니다. OpenSSL 패키지에는 인증서를 생성하고 서명하기 위한 기본 명령줄 유틸리티가 포함되어 있습니다. OpenSSL 명령줄 유틸리티에 대한 전체 문서는 http://www.openssl.org/docs 에서 확인할 수 있습니다.

개인 CA를 설정하려면 2.5절. “자체 인증서 생성” 의 지침을 참조하십시오.

호스트를 선택하는 것은 개인 CA를 설정하는 데 중요한 단계입니다. CA 호스트와 연결된 보안 수준은 CA에서 서명한 인증서와 관련된 신뢰 수준을 결정합니다.

Red Hat Fuse 애플리케이션 개발 및 테스트에서 사용할 CA를 설정하는 경우 애플리케이션 개발자가 액세스할 수 있는 호스트를 사용합니다. 그러나 CA 인증서 및 개인 키를 생성할 때 보안 중요 애플리케이션이 실행되는 모든 호스트에서 CA 개인 키를 사용하지 마십시오.

배포하려는 애플리케이션의 인증서에 서명하도록 CA를 설정하는 경우 CA 호스트를 최대한 안전하게 설정합니다. 예를 들어 CA를 보호하려면 다음 예방 조치를 취합니다.

이 섹션에 설명된 단계는 OpenSSL 프로젝트의 OpenSSL 명령줄 유틸리티를 기반으로 합니다. OpenSSL 명령줄 유틸리티에 대한 추가 문서는 http://www.openssl.org/docs/ 에서 확인할 수 있습니다.

설명을 위해 CA 데이터베이스에는 다음과 같은 디렉터리 구조가 있다고 가정합니다.

여기서 X509CA 는 CA 데이터베이스의 상위 디렉터리입니다.

이 섹션에서는 자체 개인 CA를 설정하는 방법을 설명합니다. 실제 배포를 위해 CA를 설정하기 전에 2.2.3절. “개인 인증 기관” 에서 추가 노트를 읽으십시오.

자체 CA를 설정하려면 다음 단계를 수행합니다.

보안 CA 호스트에서 OpenSSL bin 디렉토리를 경로에 추가합니다.

Windows

> set PATH=OpenSSLDir\bin;%PATH%

UNIX

% PATH=OpenSSLDir/bin:$PATH; export PATH

이 단계에서는 명령줄에서 openssl 유틸리티를 사용할 수 있습니다.

새 CA를 저장할 새 디렉터리 X509CA 를 만듭니다. 이 디렉터리는 CA와 연결된 모든 파일을 보유하는 데 사용됩니다. X509CA 디렉토리에서 다음 디렉터리 계층 구조를 생성합니다.

OpenSSL 설치의 샘플 openssl.cnf 를 X509CA 디렉터리에 복사합니다.

X509CA 디렉터리의 디렉터리 구조를 반영하고 새 CA에서 사용하는 파일을 식별하도록 openssl.cnf 를 편집합니다.

openssl.cnf 파일의 [CA_default] 섹션을 다음과 같이 편집합니다.

#############################################################
[ CA_default ]

dir        = X509CA            # Where CA files are kept
certs      = $dir/certs  # Where issued certs are kept
crl_dir    = $dir/crl          # Where the issued crl are kept
database   = $dir/index.txt    # Database index file
new_certs_dir = $dir/newcerts  # Default place for new certs

certificate   = $dir/ca/new_ca.pem # The CA certificate
serial        = $dir/serial        # The current serial number
crl           = $dir/crl.pem       # The current CRL
private_key   = $dir/ca/new_ca_pk.pem  # The private key
RANDFILE      = $dir/ca/.rand
# Private random number file

x509_extensions = usr_cert  # The extensions to add to the cert
...

이 시점에서 OpenSSL 구성의 다른 세부 정보를 편집하도록 결정할 수 있습니다. 자세한 내용은 http://www.openssl.org/docs/ 을 참조하십시오.

X509CA 디렉토리에서 serial 및 index.txt 두 파일을 초기화합니다.

Windows

Windows에서 직렬 파일을 초기화하려면 다음 명령을 입력합니다.

> echo 01 > serial

Windows의 빈 파일 index.txt 를 만들려면 다음과 같이 X509CA 디렉터리의 명령줄에서 Windows 메모장을 시작합니다.

> notepad index.txt

텍스트가 포함된 대화 상자에 대한 응답으로 text.txt 파일을 찾을 수 없습니다. 새 파일을 생성하시겠습니까?, 예 를 클릭하고 메모장을 닫습니다.

UNIX

UNIX에서 직렬 파일 및 index.txt 파일을 초기화하려면 다음 명령을 입력합니다.

% echo "01" > serial
% touch index.txt

이러한 파일은 CA에서 인증서 파일의 데이터베이스를 유지 관리하는 데 사용됩니다.

다음 명령을 사용하여 자체 서명된 새 CA 인증서 및 개인 키를 생성합니다.

openssl req -x509 -new -config X509CA/openssl.cnf -days 365 -out X509CA/ca/new_ca.pem -keyout X509CA/ca/new_ca_pk.pem

이 명령은 CA 개인 키에 대한 패스 문구와 CA 고유 이름의 세부 정보를 입력하라는 메시지를 표시합니다. 예를 들면 다음과 같습니다.

Using configuration from X509CA/openssl.cnf
Generating a 512 bit RSA private key
....++
.++
writing new private key to 'new_ca_pk.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN. There are quite a few fields but you can leave
some blank. For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:IE
State or Province Name (full name) []:Co. Dublin
Locality Name (eg, city) []:Dublin
Organization Name (eg, company) []:Red Hat
Organizational Unit Name (eg, section) []:Finance
Common Name (eg, YOUR name) []:Gordon Brown
Email Address []:gbrown@redhat.com

CA 인증서 및 개인 키의 파일 이름과 위치, new_ca.pem 및 new_ca_pk.pem 이 openssl.cnf 에 지정된 값과 동일한지 확인해야 합니다(이전 단계 참조).

이제 CA로 인증서에 서명할 준비가 되었습니다.

JKS(Java 키 저장소), CertName.jks 에서 인증서를 생성하고 서명하려면 다음 하위 단계를 수행합니다.

아직 수행하지 않은 경우 경로에 Java bin 디렉토리를 추가합니다.

Windows

> set PATH=JAVA_HOME\bin;%PATH%

UNIX

% PATH=JAVA_HOME/bin:$PATH; export PATH

이 단계에서는 명령줄에서 keytool 유틸리티를 사용할 수 있습니다.

명령 프롬프트를 열고 키 저장소 파일 KeystoreDir 을 저장하는 디렉터리로 디렉터리를 변경합니다. 다음 명령을 실행합니다.

keytool -genkey -dname "CN=Alice, OU=Engineering, O=Progress, ST=Co. Dublin, C=IE" -validity 365 -alias CertAlias -keypass CertPassword -keystore CertName.jks -storepass CertPassword

-genkey 옵션으로 호출되는 이 keytool 명령은 X.509 인증서 및 일치하는 개인 키를 생성합니다. 인증서와 키는 모두 새로 생성된 키 저장소인 CertName.jks의 키 항목에 배치됩니다. 지정된 키 저장소 CertName.jks 이므로 명령을 실행하기 전에는 존재하지 않아 keytool 에서 새 키 저장소를 암시적으로 생성합니다.

-dname 및 -validity 플래그는 새로 생성된 X.509 인증서의 내용을 정의하여 각각 제목 DN과 만료 날짜를 지정합니다. DN 형식에 대한 자세한 내용은 부록 A. ASN.1 및 Distinguished Names 을 참조하십시오.

제목 DN의 일부 부분은 CA 인증서의 값과 일치해야 합니다( openssl.cnf 파일의 CA 정책 섹션에 지정되어 있음). 기본 openssl.cnf 파일은 다음 항목이 일치해야 합니다.

다음과 같이 CertName.jks 인증서에 대한 새 CSR(인증서 서명 요청)을 생성합니다.

keytool -certreq -alias CertAlias -file CertName_csr.pem -keypass CertPassword -keystore CertName.jks -storepass CertPassword

이 명령은 CSR을 CertName_csr.pem 파일로 내보냅니다.

다음과 같이 CA를 사용하여 CSR에 서명합니다.

openssl ca -config X509CA/openssl.cnf -days 365 -in CertName_csr.pem -out CertName.pem

인증서에 서명하려면 CA 개인 키 전달 문구를 입력해야 합니다( 2.5.2절. “자체 CA 설정”참조).

서명된 인증서 CertName.pem 을 다음과 같이 PEM 전용 형식으로 변환합니다.

openssl x509 -in CertName.pem -out CertName.pem -outform PEM

다음과 같이 CA 인증서 파일과 CertName.pem 인증서 파일을 연결합니다.

Windows

copy CertName.pem + X509CA\ca\new_ca.pem CertName.chain

UNIX

cat CertName.pem X509CA/ca/new_ca.pem> CertName.chain

다음과 같이 인증서의 전체 인증서 체인을 가져와 키 저장소 CertName.jks 를 업데이트합니다.

keytool -import -file CertName.chain -keypass CertPassword -keystore CertName.jks -storepass CertPassword

2~7단계를 반복하여 시스템에 대한 전체 인증서 세트를 생성합니다.

2.5.2절. “자체 CA 설정” 에 설명된 대로 개인 CA를 설정한 경우 이제 자체 인증서를 생성하고 서명할 준비가 된 것입니다.

PKCS#12 형식 CertName.p12 에서 인증서를 생성하고 서명하려면 다음 하위 단계를 수행합니다.

아직 수행하지 않은 경우 다음과 같이 OpenSSL bin 디렉토리를 경로에 추가합니다.

Windows

> set PATH=OpenSSLDir\bin;%PATH%

UNIX

% PATH=OpenSSLDir/bin:$PATH; export PATH

이 단계에서는 명령줄에서 openssl 유틸리티를 사용할 수 있습니다.

인증서가 URL 무결성 검사를 적용하는 HTTPS 서버용이고 다중 홈 호스트 또는 여러 DNS 이름 별칭이 있는 호스트(예: 다중 홈 웹 서버에 인증서를 배포하는 경우)에 서버를 배포하려는 경우입니다. 이 경우 인증서 ID는 여러 호스트 이름과 일치해야 하며 subjectAltName 인증서 확장만 추가할 수 있습니다( 2.4절. “HTTPS 인증서에 대한 특수 요구 사항”참조).

subjectAltName 확장자를 구성하려면 다음과 같이 CA의 openssl.cnf 파일을 편집합니다.

다음과 같이 CertName.p12 인증서에 대한 새 CSR(인증서 서명 요청)을 생성합니다.

openssl req -new -config X509CA/openssl.cnf -days 365 -out X509CA/certs/CertName_csr.pem -keyout X509CA/certs/CertName_pk.pem

이 명령은 인증서의 개인 키에 대한 패스 문구와 인증서의 고유 이름에 대한 정보를 입력하라는 메시지를 표시합니다.

CSR 고유 이름의 일부 항목은 CA 인증서의 값과 일치해야 합니다( openssl.cnf 파일의 CA 정책 섹션에서 지정됨). 기본 openssl.cnf 파일을 사용하려면 다음 항목이 일치해야 합니다.

인증서 제목 DN의 일반 이름은 일반적으로 인증서 소유자의 ID를 나타내는 데 사용되는 필드입니다. 일반 이름은 다음 조건을 준수해야 합니다.

Using configuration from X509CA/openssl.cnf
Generating a 512 bit RSA private key
.++
.++
writing new private key to
      'X509CA/certs/CertName_pk.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN. There are quite a few fields but you can leave
some blank. For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:IE
State or Province Name (full name) []:Co. Dublin
Locality Name (eg, city) []:Dublin
Organization Name (eg, company) []:Red Hat
Organizational Unit Name (eg, section) []:Systems
Common Name (eg, YOUR name) []:Artix
Email Address []:info@redhat.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:password
An optional company name []:Red Hat

다음과 같이 CA를 사용하여 CSR에 서명합니다.

openssl ca -config X509CA/openssl.cnf -days 365 -in X509CA/certs/CertName_csr.pem -out X509CA/certs/CertName.pem

이 명령에는 new_ca.pem CA 인증서와 연결된 개인 키에 대한 암호 문구가 필요합니다. 예를 들면 다음과 같습니다.

Using configuration from X509CA/openssl.cnf
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName :PRINTABLE:'IE'
stateOrProvinceName :PRINTABLE:'Co. Dublin'
localityName :PRINTABLE:'Dublin'
organizationName :PRINTABLE:'Red Hat'
organizationalUnitName:PRINTABLE:'Systems'
commonName :PRINTABLE:'Bank Server Certificate'
emailAddress :IA5STRING:'info@redhat.com'
Certificate is to be certified until May 24 13:06:57 2000 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

인증서에 서명하려면 CA 개인 키 전달 문구를 입력해야 합니다( 2.5.2절. “자체 CA 설정”참조).

다음과 같이 CA 인증서 파일 CertName.pem 인증서 파일 및 CertName_pk.pem 개인 키 파일을 연결합니다.

Windows

copy X509CA\ca\new_ca.pem + X509CA\certspass:quotes[_CertName_].pem + X509CA\certspass:quotes[_CertName_]_pk.pem X509CA\certspass:quotes[_CertName_]_list.pem

UNIX

cat X509CA/ca/new_ca.pem X509CA/certs/CertName.pem X509CA/certs/CertName_pk.pem > X509CA/certs/CertName_list.pem

다음과 같이 CertName_list.pem 파일에서 PKCS#12 파일을 생성합니다.

openssl pkcs12 -export -in X509CA/certs/CertName_list.pem -out X509CA/certs/CertName.p12 -name "New cert"

PKCS#12 인증서를 암호화하기 위한 암호를 입력하라는 메시지가 표시됩니다. 일반적으로 이 암호는 CSR 암호와 동일합니다. 이 암호는 많은 인증서 리포지토리에 필요합니다.

3~6단계를 반복하여 시스템에 대한 전체 인증서 세트를 생성합니다.

애플리케이션이 대상 전용 인증에 대해 구성되면 대상이 클라이언트에 자체적으로 인증되지만 그림 3.1. “대상 인증만 해당” 에 표시된 대로 클라이언트는 대상 오브젝트에 인증되지 않습니다.

그림 3.1. 대상 인증만 해당

애플리케이션을 실행하기 전에 클라이언트 및 서버를 다음과 같이 설정해야 합니다.

보안 핸드셰이크 중에 서버는 인증서 체인을 클라이언트에 보냅니다( 그림 3.1. “대상 인증만 해당”참조). 그런 다음 클라이언트는 신뢰할 수 있는 CA 목록을 검색하여 서버의 인증서 체인에서 CA 인증서 중 하나와 일치하는 CA 인증서를 찾습니다.

클라이언트 측에는 대상 전용 인증에 필요한 정책 설정이 없습니다. X.509 인증서를 HTTPS 포트와 연결하지 않고 간단히 클라이언트를 구성합니다. 그러나 클라이언트에 신뢰할 수 있는 CA 인증서 목록을 제공해야 합니다( 3.2절. “신뢰할 수 있는 CA 인증서 지정”참조).

서버 측에서 서버의 XML 구성 파일에서 sec:clientAuthentication 요소에 클라이언트 인증이 필요하지 않은지 확인합니다. 이 요소는 생략할 수 있습니다. 이 경우 기본 정책에 클라이언트 인증이 필요하지 않습니다. 그러나 sec:clientAuthentication 요소가 있는 경우 다음과 같이 구성해야 합니다.

<http:destination id="{Namespace}PortName.http-destination">
  <http:tlsServerParameters secureSocketProtocol="TLSv1">
    ...

    <sec:clientAuthentication want="false" required="false"/>
  </http:tlsServerParameters>
</http:destination>

want 속성이 false(기본값)로 설정된 경우 TLS 핸드셰이크 중에 서버에서 클라이언트에서 X.509 인증서를 요청하지 않도록 지정합니다. 또한 required 속성은 false(기본값)로 설정되어 클라이언트 인증서가 TLS 핸드셰이크 중에 예외를 트리거하지 않도록 지정합니다.

또한 X.509 인증서를 서버의 HTTPS 포트와 연결하고 서버에 신뢰할 수 있는 CA 인증서 목록을 제공해야 합니다( 3.3절. “애플리케이션 자체 인증서 지정” 참조). 3.2절. “신뢰할 수 있는 CA 인증서 지정”

애플리케이션이 상호 인증을 위해 구성되면 대상은 클라이언트에 자신을 인증하고 클라이언트는 대상에 자신을 인증합니다. 이 시나리오는 그림 3.2. “상호 인증” 에 설명되어 있습니다. 이 경우 서버와 클라이언트는 각각 보안 핸드셰이크를 위한 X.509 인증서가 필요합니다.

그림 3.2. 상호 인증

애플리케이션을 실행하기 전에 클라이언트 및 서버를 다음과 같이 설정해야 합니다.

TLS 핸드셰이크 중에 서버는 인증서 체인을 클라이언트에 전송하고 클라이언트는 인증서 체인을 서버에 보냅니다. 그림 3.1. “대상 인증만 해당” 을 참조하십시오.

클라이언트 측에는 상호 인증에 필요한 정책 설정이 없습니다. X.509 인증서를 클라이언트의 HTTPS 포트와 연결하기만 하면 됩니다( 3.3절. “애플리케이션 자체 인증서 지정”참조). 클라이언트에 신뢰할 수 있는 CA 인증서 목록도 제공해야 합니다( 3.2절. “신뢰할 수 있는 CA 인증서 지정”참조).

서버 측에서 서버의 XML 구성 파일에서 클라이언트 인증을 요구 하도록 sec:clientAuthentication 요소가 구성되었는지 확인합니다. 예를 들면 다음과 같습니다.

<http:destination id="{Namespace}PortName.http-destination">
  <http:tlsServerParameters secureSocketProtocol="TLSv1">
    ...
    <sec:clientAuthentication want="true" required="true"/>
  </http:tlsServerParameters>
</http:destination>

want 속성이 true 로 설정된 경우 TLS 핸드셰이크 중에 서버에서 클라이언트에서 X.509 인증서를 요청하도록 지정합니다. required 속성도 true 로 설정되어 클라이언트 인증서가 없으면 TLS 핸드셰이크 중에 예외를 트리거하도록 지정합니다.

또한 X.509 인증서를 서버의 HTTPS 포트와 연결하고 서버에 신뢰할 수 있는 CA 인증서 목록을 제공해야 합니다( 3.3절. “애플리케이션 자체 인증서 지정”참조). 3.2절. “신뢰할 수 있는 CA 인증서 지정”

애플리케이션이 SSL/TLS 핸드셰이크 중에 X.509 인증서를 수신하는 경우 애플리케이션은 발급자 CA가 신뢰할 수 있는 CA 인증서 세트 중 하나인지 확인하여 수신된 인증서를 신뢰하지 않는지 여부를 결정합니다. 수신된 X.509 인증서가 애플리케이션의 신뢰할 수 있는 CA 인증서 중 하나에 의해 유효한 서명인 경우 인증서가 신뢰할 수 있는 것으로 간주됩니다. 그렇지 않으면 거부됩니다.

HTTPS 핸드셰이크의 일부로 X.509 인증서를 수신할 가능성이 있는 모든 애플리케이션은 신뢰할 수 있는 CA 인증서 목록을 지정해야 합니다. 예를 들어 다음과 같은 유형의 애플리케이션이 포함됩니다.

CA 인증서는 Java 키 저장소 형식으로 제공되어야 합니다.

HTTPS 전송을 위해 신뢰할 수 있는 루트 CA를 하나 이상 배포하려면 다음 단계를 수행합니다.

HTTPS 전송으로 작업할 때 애플리케이션의 인증서는 XML 구성 파일을 사용하여 배포됩니다.

HTTPS 전송을 위해 애플리케이션 자체 인증서를 배포하려면 다음 단계를 수행합니다.

전송 계층 대신 Cryostat 인코딩 계층에서 메시지 보호를 적용하면 보다 유연한 보호 정책에 액세스할 수 있습니다. 특히 Cryostat 계층은 메시지 구조를 인식하기 때문에 실제로 보호가 필요한 헤더를 암호화하고 서명하여 세분화된 수준에서 보호를 적용할 수 있습니다. 이 기능을 사용하면 보다 정교한 다중 계층 아키텍처를 지원할 수 있습니다. 예를 들어 하나의 일반 텍스트 헤더는 중간 계층(보안 인트라넷 내에 위치)을 대상으로 할 수 있지만 암호화된 헤더는 최종 대상(비보안 공용 네트워크를 통해 연결됨)을 대상으로 할 수 있습니다.

WS-SecurityPolicy 사양에 설명된 대로 다음 바인딩 유형 중 하나를 사용하여 Cryostat 메시지를 보호할 수 있습니다.

다음과 같은 보호 특성을 메시지의 일부 또는 전체에 적용할 수 있습니다.

이러한 보호 특성은 단일 메시지에서 임의로 결합될 수 있습니다. 따라서 메시지의 일부만 암호화할 수 있지만 메시지의 다른 부분은 서명만 되고 메시지의 다른 부분은 서명하고 암호화할 수 있습니다. 또한 메시지의 일부를 보호되지 않은 상태로 둘 수도 있습니다.

메시지 보호를 적용하기 위한 가장 유연한 옵션은 Cryostat 계층(sp:AsymmetricBinding 또는 sp:SymmetricBinding)에서 사용할 수 있습니다. 전송 계층(sp:TransportBinding)은 전체 메시지에 대한 보호를 적용하는 옵션만 제공합니다.

현재 Apache CXF를 사용하면 ESP 메시지의 다음 부분에 서명하거나 암호화할 수 있습니다.

메시지 보호에 필요한 모든 세부 정보가 정책을 사용하여 지정되는 것은 아닙니다. 정책은 주로 서비스에 필요한 보호의 품질을 지정하는 방법을 제공하기 위한 것입니다. 보안 토큰, 암호 등과 같은 지원 세부 정보는 별도의 제품별 메커니즘을 사용하여 제공해야 합니다. 실제로 Apache CXF에서는 블루프린트 XML 구성 파일에 일부 지원 구성 세부 정보를 제공해야 합니다. 자세한 내용은 6.2.6절. “암호화 키 및 서명 키 제공”의 내용을 참조하십시오.

여기에 설명된 시나리오는 클라이언트-서버 애플리케이션입니다. 이 애플리케이션에서는 비대칭 바인딩 정책이 클라이언트와 서버 간에 전달되는 메시지의#159 본문을 암호화하고 서명하도록 설정되어 있습니다.

그림 6.1. “기본 서명 및 암호화 시나리오” 비대칭 바인딩 정책을 WSDL 계약의 끝점과 연결하여 지정하는 기본 서명 및 암호화 시나리오에 대한 개요를 보여줍니다.

그림 6.1. 기본 서명 및 암호화 시나리오

그림 6.1. “기본 서명 및 암호화 시나리오” 의 클라이언트가 수신자의 끝점에서 동기 작업을 호출하면 요청 및 응답 메시지가 다음과 같이 처리됩니다.

비대칭 바인딩 정책은 비대칭 키 알고리즘(공용/개인 키 조합)을 사용하여 Cryostat 메시지 보호를 구현하며 Loki 계층에서 이를 수행합니다. 비대칭 바인딩에서 사용하는 암호화 및 서명 알고리즘은 SSL/TLS에서 사용하는 암호화 및 서명 알고리즘과 유사합니다. 그러나 중요한 차이점은 Cryostat 메시지 보호를 통해 메시지의 특정 부분을 선택하여 보호 할 수 있다는 것입니다 (예: 개별 헤더, 본문 또는 첨부 파일) 반면 전송 계층 보안은 전체 메시지에서만 작동할 수 있다는 것입니다.

비대칭 바인딩 정책은 끝점 정책 제목에 적용해야 합니다( “끝점 정책 제목”참조). 예를 들어 ID가 있는 비대칭 바인딩 정책이 경우 MutualCertificate10SignEncrypt_IPingService_policy 에서는 다음과 같이 정책을 끝점 바인딩에 적용할 수 있습니다.

<wsdl:binding name="MutualCertificate10SignEncrypt_IPingService" type="i0:IPingService">
  <wsp:PolicyReference URI="#MutualCertificate10SignEncrypt_IPingService_policy"/>
  ...
</wsdl:binding>

AsymmetricBinding 요소에는 다음과 같은 구문이 있습니다.

<sp:AsymmetricBinding xmlns:sp="..." ... >
  <wsp:Policy xmlns:wsp="...">
  (
   <sp:InitiatorToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:InitiatorToken>
  ) | (
   <sp:InitiatorSignatureToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:InitiatorSignatureToken>
   <sp:InitiatorEncryptionToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:InitiatorEncryptionToken>
  )
  (
   <sp:RecipientToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:RecipientToken>
  ) | (
   <sp:RecipientSignatureToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:RecipientSignatureToken>
   <sp:RecipientEncryptionToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:RecipientEncryptionToken>
  )
   <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite>
   <sp:Layout ... > ... </sp:Layout> ?
   <sp:IncludeTimestamp ... /> ?
   <sp:EncryptBeforeSigning ... /> ?
   <sp:EncryptSignature ... /> ?
   <sp:ProtectTokens ... /> ?
   <sp:OnlySignEntireHeadersAndBody ... /> ?
   ...
  </wsp:Policy>
  ...
</sp:AsymmetricBinding>

예 6.4. “Asymmetric Binding의 예” 서명 및 암호화를 사용한 메시지 보호를 지원하는 비대칭 바인딩의 예를 보여줍니다. 여기서 서명 및 암호화는 공개/개인 키(즉, 비대칭 암호화 사용) 쌍을 사용하여 수행됩니다. 그러나 이 예제에서는 서명하고 암호화해야 하는 메시지의 부분을 지정하지 않습니다. 이를 수행하는 방법에 대한 자세한 내용은 6.2.5절. “암호화 및 서명할 메시지의 일부 지정” 을 참조하십시오.

<wsp:Policy wsu:Id="MutualCertificate10SignEncrypt_IPingService_policy">
  <wsp:ExactlyOne>
    <wsp:All>
      <sp:AsymmetricBinding
          xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:InitiatorToken>
            <wsp:Policy>
              <sp:X509Token
                  sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                <wsp:Policy>
                  <sp:WssX509V3Token10/>
                </wsp:Policy>
              </sp:X509Token>
            </wsp:Policy>
          </sp:InitiatorToken>
          <sp:RecipientToken>
            <wsp:Policy>
              <sp:X509Token
                  sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
                <wsp:Policy>
                  <sp:WssX509V3Token10/>
                </wsp:Policy>
              </sp:X509Token>
            </wsp:Policy>
          </sp:RecipientToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic256/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
          <sp:Layout>
            <wsp:Policy>
              <sp:Lax/>
            </wsp:Policy>
          </sp:Layout>
          <sp:IncludeTimestamp/>
          <sp:EncryptSignature/>
          <sp:OnlySignEntireHeadersAndBody/>
        </wsp:Policy>
      </sp:AsymmetricBinding>
      <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:MustSupportRefKeyIdentifier/>
          <sp:MustSupportRefIssuerSerial/>
        </wsp:Policy>
      </sp:Wss10>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

이니시에이터 토큰은 이니시에이터 가 소유한 공개/개인 키 쌍을 나타냅니다. 이 토큰은 다음과 같이 사용됩니다.

혼동적으로 이 토큰은 이니시에이터 와 수신자가 모두 사용합니다. 그러나 초기자만 개인 키에 액세스할 수 있으므로 이러한 경우 토큰은 이니시에이터에 속한다고 할 수 있습니다. 6.2.2절. “기본 서명 및 암호화 시나리오” 에서 이니시에이터 토큰은 인증서인 Alice입니다.

이 요소에는 표시된 대로 중첩된 wsp:Policy 요소 및 sp:X509Token 요소가 포함되어야 합니다. sp:IncludeToken 속성은 AlwaysToRecipient 로 설정되어 있으며, 이는 수신자에게 전송되는 모든 메시지와 함께 Alice의 공개 키를 포함하도록 런타임에 지시합니다. 이 옵션은 수신자가 이니시에이터의 인증서를 사용하여 인증을 수행하려는 경우 유용합니다. 가장 깊이 중첩된 요소인 WssX509V3Token10 은 선택 사항입니다. X.509 인증서가 준수해야 하는 사양 버전을 지정합니다. 여기에서는 다음 대안(또는 none)을 지정할 수 있습니다.

수신자 토큰은 수신자 가 소유한 공개/개인 키 쌍을 나타냅니다. 이 토큰은 다음과 같이 사용됩니다.

혼동적으로 이 토큰은 수신자 와 이니시에이터에서 모두 사용됩니다. 그러나 수신자만 개인 키에 액세스할 수 있으므로 이러한 경우 토큰은 수신자에 속한다고 할 수 있습니다. 6.2.2절. “기본 서명 및 암호화 시나리오” 에서 수신자 토큰은 인증서인 Cryostat입니다.

이 요소에는 표시된 대로 중첩된 wsp:Policy 요소 및 sp:X509Token 요소가 포함되어야 합니다. sp:IncludeToken 속성은 응답 메시지에 Cryostat의 공개 키를 포함할 필요가 없기 때문에 Never 로 설정됩니다.

이 요소는 서명 및 암호화에 사용할 암호화 알고리즘 제품군을 지정합니다. 사용 가능한 알고리즘 모음에 대한 자세한 내용은 6.2.7절. “알고리즘 모음 지정” 을 참조하십시오.

이 요소는 보안 헤더가 Cryostat 메시지에 추가되는 순서에 조건을 적용할지 여부를 지정합니다. sp:Lax 요소는 보안 헤더 순서에 조건이 적용되지 않도록 지정합니다. sp:Lax 의 대안은 sp: Ssimplet ,sp:LaxTimestampFirst 또는 sp:LaxTimestampLast 입니다.

이 요소가 정책에 포함된 경우 런타임은 wsu:Timestamp 요소를 wsse:Security 헤더에 추가합니다. 기본적으로 타임스탬프는 포함되지 않습니다.

메시지 부분에 암호화 및 서명이 모두 적용되는 경우 이러한 작업이 수행되는 순서를 지정해야 합니다. 기본 순서는 암호화하기 전에 서명하는 것입니다. 그러나 이 요소를 비대칭 정책에 포함하는 경우 서명 전에 암호화하도록 순서가 변경됩니다.

이 요소는 메시지 서명이 6.2.6절. “암호화 키 및 서명 키 제공”에 설명된 대로 지정된 암호화 토큰에 의해 암호화되도록 지정합니다. 기본값은 false입니다.

이 요소는 서명이 해당 서명을 생성하는 데 사용되는 토큰을 포함해야 함을 지정합니다. 기본값은 false입니다.

이 요소는 서명이 전체 본문 또는 전체 헤더에 만 적용할 수 있고 본문의 하위 요소 또는 헤더의 하위 요소에만 적용할 수 있도록 지정합니다. 이 옵션을 활성화하면 sp:Signed Cryostats 어설션을 효과적으로 사용할 수 없습니다( 6.2.5절. “암호화 및 서명할 메시지의 일부 지정”참조).

대칭 바인딩 정책은 대칭 키 알고리즘(공유 비밀 키)을 사용하여 Cryostat 메시지 보호를 구현하며 Loki 계층에서 이를 수행합니다. 대칭 바인딩의 예로는 Kerberos 프로토콜 및 WS-SecureConversation 프로토콜이 있습니다.

대칭 바인딩 정책은 끝점 정책 주체에 적용해야 합니다( “끝점 정책 제목”참조). 예를 들어 ID가 있는 대칭 바인딩 정책이 SecureConversation_MutualCertificate10SignEncrypt_IPingService_policy 인 경우 다음과 같이 정책을 엔드포인트 바인딩에 적용할 수 있습니다.

<wsdl:binding name="SecureConversation_MutualCertificate10SignEncrypt_IPingService" type="i0:IPingService">
  <wsp:PolicyReference URI="#SecureConversation_MutualCertificate10SignEncrypt_IPingService_policy"/>
  ...
</wsdl:binding>

SymmetricBinding 요소에는 다음과 같은 구문이 있습니다.

<sp:SymmetricBinding xmlns:sp="..." ... >
  <wsp:Policy xmlns:wsp="...">
  (
   <sp:EncryptionToken ... >
     <wsp:Policy> ... </wsp:Policy>
   </sp:EncryptionToken>
   <sp:SignatureToken ... >
     <wsp:Policy> ... </wsp:Policy>
   </sp:SignatureToken>
  ) | (
   <sp:ProtectionToken ... >
     <wsp:Policy> ... </wsp:Policy>
   </sp:ProtectionToken>
  )
   <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite>
   <sp:Layout ... > ... </sp:Layout> ?
   <sp:IncludeTimestamp ... /> ?
   <sp:EncryptBeforeSigning ... /> ?
   <sp:EncryptSignature ... /> ?
   <sp:ProtectTokens ... /> ?
   <sp:OnlySignEntireHeadersAndBody ... /> ?
   ...
  </wsp:Policy>
  ...
</sp:SymmetricBinding>

예 6.5. “Symmetric Binding의 예” 서명 및 암호화를 사용한 메시지 보호를 지원하는 대칭 바인딩의 예를 보여줍니다. 여기서 서명 및 암호화는 단일 대칭 키(즉, 대칭 암호화 사용)를 사용하여 수행됩니다. 그러나 이 예제에서는 서명하고 암호화해야 하는 메시지의 부분을 지정하지 않습니다. 이를 수행하는 방법에 대한 자세한 내용은 6.2.5절. “암호화 및 서명할 메시지의 일부 지정” 을 참조하십시오.

<wsp:Policy wsu:Id="SecureConversation_MutualCertificate10SignEncrypt_IPingService_policy">
  <wsp:ExactlyOne>
    <wsp:All>
      <sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:ProtectionToken>
            <wsp:Policy>
              <sp:SecureConversationToken>
                ...
              </sp:SecureConversationToken>
            </wsp:Policy>
          </sp:ProtectionToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic256/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
          <sp:Layout>
            <wsp:Policy>
              <sp:Lax/>
            </wsp:Policy>
          </sp:Layout>
          <sp:IncludeTimestamp/>
          <sp:EncryptSignature/>
          <sp:OnlySignEntireHeadersAndBody/>
        </wsp:Policy>
      </sp:SymmetricBinding>
      <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:MustSupportRefKeyIdentifier/>
          <sp:MustSupportRefIssuerSerial/>
        </wsp:Policy>
      </sp:Wss10>
      ...
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

이 요소는 메시지에 서명하고 암호화하는 데 사용할 대칭 토큰을 지정합니다. 예를 들어 여기에 WS-SecureConversation 토큰을 지정할 수 있습니다.

작업에 서명 및 암호화에 고유 토큰을 사용하려면 이 요소 대신 sp:SignatureToken 요소와 sp:EncryptionToken 요소를 사용합니다.

이 요소는 메시지 서명에 사용할 대칭 토큰을 지정합니다. sp:EncryptionToken 요소와 함께 사용해야 합니다.

이 요소는 메시지를 암호화하는 데 사용할 대칭 토큰을 지정합니다. sp:SignatureToken 요소와 함께 사용해야 합니다.

이 요소는 서명 및 암호화에 사용할 암호화 알고리즘 제품군을 지정합니다. 사용 가능한 알고리즘 모음에 대한 자세한 내용은 6.2.7절. “알고리즘 모음 지정” 을 참조하십시오.

이 요소는 보안 헤더가 Cryostat 메시지에 추가되는 순서에 조건을 적용할지 여부를 지정합니다. sp:Lax 요소는 보안 헤더 순서에 조건이 적용되지 않도록 지정합니다. sp:Lax 의 대안은 sp: Ssimplet ,sp:LaxTimestampFirst 또는 sp:LaxTimestampLast 입니다.

이 요소가 정책에 포함된 경우 런타임은 wsu:Timestamp 요소를 wsse:Security 헤더에 추가합니다. 기본적으로 타임스탬프는 포함되지 않습니다.

메시지 부분에 암호화 및 서명이 모두 적용되면 이러한 작업이 수행되는 순서를 지정해야 합니다. 기본 순서는 암호화하기 전에 서명하는 것입니다. 그러나 대칭 정책에 이 요소를 포함하는 경우 서명 전에 암호화하도록 순서가 변경됩니다.

이 요소는 메시지 서명이 암호화되어야 함을 지정합니다. 기본값은 false입니다.

이 요소는 서명이 해당 서명을 생성하는 데 사용되는 토큰을 포함해야 함을 지정합니다. 기본값은 false입니다.

이 요소는 서명이 전체 본문 또는 전체 헤더에 만 적용할 수 있고 본문의 하위 요소 또는 헤더의 하위 요소에만 적용할 수 있도록 지정합니다. 이 옵션을 활성화하면 sp:Signed Cryostats 어설션을 효과적으로 사용할 수 없습니다( 6.2.5절. “암호화 및 서명할 메시지의 일부 지정”참조).

암호화 및 서명은 각각 기밀성과 무결성이라는 두 가지 종류의 보호를 제공합니다. WS-SecurityPolicy 보호 어설션은 보호 대상 메시지의 일부를 지정하는 데 사용됩니다. 보호 메커니즘에 대한 자세한 내용은 관련 바인딩 정책에 별도로 지정됩니다(x6.2.3절. “AsymmetricBinding 정책 지정”, 6.2.4절. “SymmetricBinding 정책 지정”, 6.1절. “전송 계층 메시지 보호”참조).

여기에 설명된 보호 어설션은 Cryostat 메시지의 기능에 적용되기 때문에 issuer security와 함께 사용하기 위한 것입니다. 물론 이러한 정책은 특정 부분이 아닌 전체 메시지에 보호를 적용하는 전송 바인딩(예: HTTPS)에 의해 충족될 수 있습니다.

보호 어설션은 메시지 정책 주체에 적용해야 합니다( “메시지 정책 제목”참조). 즉, WSDL 바인딩의 wsdl:input,wsdl:output 또는 wsdl:fault 요소 내에 배치해야 합니다. 예를 들어 ID가 있는 보호 정책인 MutualCertificate10SignEncrypt_IPingService_header_Input_policy 인 경우 다음과 같이 정책을 wsdl:input 메시지 부분에 적용할 수 있습니다.

<wsdl:operation name="header">
  <soap:operation soapAction="http://InteropBaseAddress/interop/header" style="document"/>
  <wsdl:input name="headerRequest">
    <wsp:PolicyReference
        URI="#MutualCertificate10SignEncrypt_IPingService_header_Input_policy"/>
      <soap:header message="i0:headerRequest_Headers" part="CustomHeader" use="literal"/>
      <soap:body use="literal"/>
    </wsdl:input>
    ...
</wsdl:operation>

다음 WS-SecurityPolicy 보호 어설션은 Apache CXF에서 지원합니다.

SignedParts 요소에는 다음과 같은 구문이 있습니다.

<sp:SignedParts xmlns:sp="..." ... >
  <sp:Body />?
  <sp:Header Name="xs:NCName"? Namespace="xs:anyURI" ... />*
  <sp:Attachments />?
  ...
</sp:SignedParts>

EncryptedParts 요소에는 다음과 같은 구문이 있습니다.

<sp:EncryptedParts xmlns:sp="..." ... >
  <sp:Body/>?
  <sp:Header Name="xs:NCName"? Namespace="xs:anyURI" ... />*
  <sp:Attachments />?
  ...
</sp:EncryptedParts>

예 6.6. “무결성 및 암호화 정책 지원” 두 가지 보호 어설션, 즉 서명된 부분 어설션 및 암호화된 부분 어설션을 결합하는 정책을 표시합니다. 이 정책이 메시지 부분에 적용되면 영향을 받는 메시지 본문이 서명되고 암호화됩니다. 또한 CustomHeader 라는 메시지 헤더가 서명됩니다.

<wsp:Policy wsu:Id="MutualCertificate10SignEncrypt_IPingService_header_Input_policy">
    <wsp:ExactlyOne>
        <wsp:All>
            <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <sp:Body/>
                <sp:Header Name="CustomHeader" Namespace="http://InteropBaseAddress/interop"/>
            </sp:SignedParts>
            <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <sp:Body/>
            </sp:EncryptedParts>
        </wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

이 요소는 보호(암호화 또는 서명)가 메시지의 본문에 적용되도록 지정합니다. 보호는 전체 메시지 본문(즉, soap:Body 요소, 해당 특성 및 해당 콘텐츠)에 적용됩니다.

이 요소는 Name 특성 및 Namespace 특성을 사용하여 헤더의 로컬 이름으로 지정된 Cryostat 헤더에 보호가 적용되도록 지정합니다. 보호는 특성 및 해당 콘텐츠를 포함하여 전체 메시지 헤더에 적용됩니다.

이 요소는 Attachments(SwA) 첨부 파일이 있는 모든 #159가 보호되도록 지정합니다.

표준 WS-SecurityPolicy 정책은 보안 요구 사항을 일부 세부적으로 지정하도록 설계되었습니다(예: 보안 프로토콜, 보안 알고리즘, 토큰 유형, 인증 요구 사항 등)은 모두 설명되어 있습니다. 그러나 표준 정책 어설션은 키 및 자격 증명과 같은 관련 보안 데이터를 지정하기 위한 메커니즘을 제공하지 않습니다. WS-SecurityPolicy는 독점 메커니즘을 통해 필요한 보안 데이터를 제공할 것으로 예상합니다. Apache CXF에서는 블루프린트 XML 구성을 통해 관련 보안 데이터가 제공됩니다.

클라이언트의 요청 컨텍스트 또는 끝점 컨텍스트에서 속성을 설정하여 애플리케이션의 암호화 키 및 서명 키를 지정할 수 있습니다( “블루프린트 구성에 암호화 및 서명 속성 추가”참조). 설정할 수 있는 속성은 표 6.1. “암호화 및 서명 속성” 에 표시됩니다.

이전 속성의 이름은 사용되는 내용을 정확하게 반영하지 않기 때문에 잘 선택되지 않습니다. security.signature.properties 로 지정된 키는 서명 및 암호 해독에 실제로 사용됩니다. security.encryption.properties 로 지정된 키는 실제로 서명 암호화 및 검증에 사용됩니다.

Apache CXF 애플리케이션에서 WS-Policy 정책을 사용하려면 먼저 기본 CXF 버스에 정책 기능을 추가해야 합니다. 다음 블루프린트 구성 조각에 표시된 것처럼 p:policies 요소를 CXF 버스에 추가합니다.

<beans xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xmlns:cxf="http://cxf.apache.org/core"
       xmlns:p="http://cxf.apache.org/policy" ... >

    <cxf:bus>
        <cxf:features>
            <p:policies/>
            <cxf:logging/>
        </cxf:features>
    </cxf:bus>
    ...
</beans>

다음 예제에서는 지정된 서비스 유형의 프록시에 서명 및 암호화 속성을 추가하는 방법을 보여줍니다( jaxws:client 요소의 name 속성으로 서비스 이름이 지정됨). 속성은 WSS4J 속성 파일에 저장됩니다. 여기서 alice.properties 에는 서명 키의 속성이 포함되어 있으며 bob.properties 에는 암호화 키의 속성이 포함되어 있습니다.

<beans ... >
    <jaxws:client name="{http://InteropBaseAddress/interop}MutualCertificate10SignEncrypt_IPingService"
                  createdFromAPI="true">
        <jaxws:properties>
            <entry key="ws-security.signature.properties" value="etc/alice.properties"/>
            <entry key="ws-security.encryption.properties" value="etc/bob.properties"/>
        </jaxws:properties>
    </jaxws:client>
    ...
</beans>

실제로 속성 이름에서는 명확하지 않지만 이러한 각 키는 클라이언트 측의 두 가지 용도로 사용됩니다.

이러한 혼동이 있는 경우 자세한 설명은 6.2.2절. “기본 서명 및 암호화 시나리오” 에서 참조하십시오.

다음 예제에서는 signature-WS 엔드포인트에 서명 및 암호화 속성을 추가하는 방법을 보여줍니다. 속성 파일 bob.properties 에는 서명 키 및 속성 파일의 속성이 포함되어 있습니다. alice.properties 에는 암호화 키의 속성이 포함되어 있습니다(클라이언트 구성의 역임).

<beans ... >
    <jaxws:endpoint
       name="{http://InteropBaseAddress/interop}MutualCertificate10SignEncrypt_IPingService"
       id="MutualCertificate10SignEncrypt"
       address="http://localhost:9002/MutualCertificate10SignEncrypt"
       serviceName="interop:PingService10"
       endpointName="interop:MutualCertificate10SignEncrypt_IPingService"
       implementor="interop.server.MutualCertificate10SignEncrypt">

        <jaxws:properties>
            <entry key="security.signature.properties" value="etc/bob.properties"/>
            <entry key="security.encryption.properties" value="etc/alice.properties"/>
        </jaxws:properties>

    </jaxws:endpoint>
    ...
</beans>

이러한 각 키는 서버 측의 두 가지 용도로 사용됩니다.

Apache CXF는 WSS4J 속성 파일을 사용하여 암호화 및 서명에 필요한 공개 키와 개인 키를 로드합니다. 표 6.2. “WSS4J 키 저장소 속성” 이러한 파일에서 설정할 수 있는 속성에 대해 설명합니다.

예를 들어 etc/alice.properties 파일에는 다음과 같이 PKCS#12 파일 certs/alice.pfx 를 로드하는 속성 설정이 포함되어 있습니다.

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin

org.apache.ws.security.crypto.merlin.keystore.type=PKCS12
org.apache.ws.security.crypto.merlin.keystore.password=password
org.apache.ws.security.crypto.merlin.keystore.file=certs/alice.pfx

etc/bob.properties 파일에는 다음과 같이 PKCS#12 파일 certs/bob.pfx 를 로드하는 속성 설정이 포함되어 있습니다.

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin

org.apache.ws.security.crypto.merlin.keystore.password=password

# for some reason, bouncycastle has issues with bob.pfx
org.apache.ws.security.crypto.merlin.keystore.provider=SunJSSE
org.apache.ws.security.crypto.merlin.keystore.type=PKCS12
org.apache.ws.security.crypto.merlin.keystore.file=certs/bob.pfx

암호화 키와 서명 키를 로드하는 다른 방법은 표 6.3. “Crypto 오브젝트 지정을 위한 속성” 에 표시된 속성을 사용하여 관련 키를 로드하는 Crypto 오브젝트를 지정하는 것입니다. 이를 위해서는 WSS4J Crypto 인터페이스 org.apache.ws.security.components.crypto.Crypto 의 자체 구현을 제공해야 합니다.

예 6.7. “WSS4J Crypto 인터페이스” 프로그래밍을 통해 암호화 키와 서명 키를 제공하려는 경우 구현할 수 있는 Crypto 인터페이스의 정의를 표시합니다. 자세한 내용은 WSS4J 홈 페이지를 참조하십시오.

// Java
package org.apache.ws.security.components.crypto;

import org.apache.ws.security.WSSecurityException;

import java.io.InputStream;
import java.math.BigInteger;
import java.security.KeyStore;
import java.security.PrivateKey;
import java.security.cert.Certificate;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;

public interface Crypto {
    X509Certificate loadCertificate(InputStream in)
    throws WSSecurityException;

    X509Certificate[] getX509Certificates(byte[] data, boolean reverse)
    throws WSSecurityException;

    byte[] getCertificateData(boolean reverse, X509Certificate[] certs)
    throws WSSecurityException;

    public PrivateKey getPrivateKey(String alias, String password)
    throws Exception;

    public X509Certificate[] getCertificates(String alias)
    throws WSSecurityException;

    public String getAliasForX509Cert(Certificate cert)
    throws WSSecurityException;

    public String getAliasForX509Cert(String issuer)
    throws WSSecurityException;

    public String getAliasForX509Cert(String issuer, BigInteger serialNumber)
    throws WSSecurityException;

    public String getAliasForX509Cert(byte[] skiBytes)
    throws WSSecurityException;

    public String getDefaultX509Alias();

    public byte[] getSKIBytesFromCert(X509Certificate cert)
    throws WSSecurityException;

    public String getAliasForX509CertThumb(byte[] thumb)
    throws WSSecurityException;

    public KeyStore getKeyStore();

    public CertificateFactory getCertificateFactory()
    throws WSSecurityException;

    public boolean validateCertPath(X509Certificate[] certs)
    throws WSSecurityException;

    public String[] getAliasesForDN(String subjectDN)
    throws WSSecurityException;
}

알고리즘 모음은 서명, 암호화, 메시지 다이제스트 생성 등과 같은 작업을 수행하기 위한 일관된 암호화 알고리즘 컬렉션입니다.

참조용으로 이 섹션에서는 WS-SecurityPolicy 사양에 정의된 알고리즘 모음에 대해 설명합니다. 그러나 특정 알고리즘 모음을 사용할 수 있는지 여부는 기본 보안 공급자에 따라 다릅니다. Apache CXF 보안은 JCE(Pluggable Java Cryptography Extension) 및 JSSE(Java Secure Socket Extension) 계층을 기반으로 합니다. 기본적으로 Apache CXF는 Sun의 JSSE 공급자로 구성되며, Sun의 JSSE 참조 가이드 의 부록 A 에 설명된 암호화 제품군을 지원합니다.

AlgorithmSuite 요소에는 다음과 같은 구문이 있습니다.

<sp:AlgorithmSuite xmlns:sp="..." ... >
  <wsp:Policy xmlns:wsp="...">
   (<sp:Basic256 ... /> |
    <sp:Basic192 ... /> |
    <sp:Basic128 ... /> |
    <sp:TripleDes ... /> |
    <sp:Basic256Rsa15 ... /> |
    <sp:Basic192Rsa15 ... /> |
    <sp:Basic128Rsa15 ... /> |
    <sp:TripleDesRsa15 ... /> |
    <sp:Basic256Sha256 ... /> |
    <sp:Basic192Sha256 ... /> |
    <sp:Basic128Sha256 ... /> |
    <sp:TripleDesSha256 ... /> |
    <sp:Basic256Sha256Rsa15 ... /> |
    <sp:Basic192Sha256Rsa15 ... /> |
    <sp:Basic128Sha256Rsa15 ... /> |
    <sp:TripleDesSha256Rsa15 ... /> |
    ...)
    <sp:InclusiveC14N ... /> ?
    <sp:SOAPNormalization10 ... /> ?
    <sp:STRTransform10 ... /> ?
   (<sp:XPath10 ... /> |
    <sp:XPathFilter20 ... /> |
    <sp:AbsXPath ... /> |
    ...)?
    ...
  </wsp:Policy>
  ...
</sp:AlgorithmSuite>

알고리즘 제품군 어설션은 많은 대체 알고리즘(예: Basic256)을 지원합니다. 알고리즘 모음 대안에 대한 자세한 설명은 표 6.4. “알고리즘 모음” 을 참조하십시오.

표 6.4. “알고리즘 모음” WS-SecurityPolicy에서 지원하는 알고리즘 모음에 대한 요약을 제공합니다. 열 제목은 다음과 같이 다양한 유형의 암호화 알고리즘을 나타냅니다. \[Dig]는 다이제스트 알고리즘입니다. \[Enc]는 암호화 알고리즘입니다. \[Sym KW]는 대칭 키 래핑 알고리즘입니다. \[Enc KW]는 비대칭 키 래핑 알고리즘입니다. \[Enc KD]는 암호화 키 파생 알고리즘입니다. \[Enc KD] is the symmetric key-wrap algorithm; \[Sym KW] is the symmetric key-wrap algorithm; \[Enc KD]

WS-SecurityPolicy에서 지원하는 암호화 알고리즘 유형은 다음과 같습니다.

대칭 키 서명 속성 [Sym Sig]은 대칭 키를 사용하여 서명을 생성하는 알고리즘을 지정합니다. WS-SecurityPolicy는 HmacSha1 알고리즘이 항상 사용되도록 지정합니다.

HmacSha1 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2000/09/xmldsig#hmac-sha1

비대칭 키 서명 속성 [Asym Sig]은 비대칭 키를 사용하여 서명을 생성하는 알고리즘을 지정합니다. WS-SecurityPolicy는 RsaSha1 알고리즘이 항상 사용되도록 지정합니다.

RsaSha1 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2000/09/xmldsig#rsa-sha1

다이제스트 속성인 [Dig]는 메시지 다이제스트 값을 생성하는 데 사용되는 알고리즘을 지정합니다. WS-SecurityPolicy는 sha 1 및 Sha 256 이라는 두 가지 대체 다이제스트 알고리즘을 지원합니다.

Sha1 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2000/09/xmldsig#sha1

Sha256 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#sha256

암호화 속성인 [Enc]는 데이터를 암호화하는 데 사용되는 알고리즘을 지정합니다. WS-SecurityPolicy는 다음과 같은 암호화 알고리즘을 지원합니다. Aes256,Aes192,Aes128,TripleDes.

Aes256 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#aes256-cbc

Aes192 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#aes192-cbc

Aes128 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#aes128-cbc

TripleDes 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#tripledes-cbc

대칭 키 래핑 속성인 [Sym KW]는 대칭 키 서명 및 암호화에 사용되는 알고리즘을 지정합니다. WS-SecurityPolicy는 다음과 같은 대칭 키 래핑 알고리즘을 지원합니다. KwAes256,KwAes192,KwAes128,KwTripleDes.

KwAes256 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#kw-aes256

KwAes192 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#kw-aes192

KwAes128 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#kw-aes128

KwTripleDes 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#tripledes-cbc

비대칭 키 래핑 속성인 [Asym KW]는 비대칭 키를 서명하고 암호화하는 데 사용되는 알고리즘을 지정합니다. WS-SecurityPolicy는 다음과 같은 비대칭 키 래핑 알고리즘을 지원합니다. KwRsaOaep,KwRsa15.

KwRsaOaep 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

KwRsa15 알고리즘은 다음 URI로 식별됩니다.

http://www.w3.org/2001/04/xmlenc#rsa-1_5

계산된 키 속성 [Comp Key]는 파생 키를 계산하는 데 사용되는 알고리즘을 지정합니다. 보안 당사자가 공유 비밀 키의 지원과 통신할 때(예: WS-SecureConversation 사용 시), 적대적인 타사의 분석을 위해 너무 많은 데이터를 노출하지 않으려면 원래 공유 키 대신 파생 키를 사용하는 것이 좋습니다. WS-SecurityPolicy는 PSha1 알고리즘이 항상 사용되도록 지정합니다.

PSha1 알고리즘은 다음 URI로 식별됩니다.

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha1

암호화 키 파생 속성인 [Enc KD]는 파생 암호화 키를 계산하는 데 사용되는 알고리즘을 지정합니다. WS-SecurityPolicy는 다음과 같은 암호화 키 파생 알고리즘을 지원합니다. PSha1L256,PSha1L192,PSha1L128.

PSha1 알고리즘은 다음 URI로 식별됩니다( PSha1L256,PSha1L192 및 PSha1L128 에 동일한 알고리즘이 사용됩니다. 키 길이는 다릅니다).

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha1

서명 키 파생 속성인 [Sig KD]는 파생된 서명 키를 계산하는 데 사용되는 알고리즘을 지정합니다. WS-SecurityPolicy는 다음과 같은 서명 키 파생 알고리즘을 지원합니다. PSha1L192,PSha1L128.

표 6.5. “키 길이 속성” WS-SecurityPolicy에서 지원되는 최소 및 최대 키 길이를 표시합니다.

최소 대칭 키 길이인 [Min SKL] 값은 선택한 알고리즘 모음에 따라 다릅니다.