| Info |
|---|
Copyright Statement The specifications and information regarding the product in this manual are subject to change without prior notice. All statements, information, and recommendations in this manual are believed to be accurate but are presented without warranty of any kind, expressed or implied. Users must take full responsibility for their use of any products. © Verisec Freja eID 2018. All rights reserved. |
IntroductionThank you for subscribing to Freja eID services. Freja eID is an electronic identification (eID) solution for citizens and organisations which can be used for identity assertion, authentication and signing. The essential part of Freja eID service is a smartphone application used for login and signing to all the services that are connected to the user´s eID. The second part is a web portal – My Pages – where the user can control how their eID is to be used and has a full record of user history. In terms of relying partiesRelying Parties (RPs), Freja eID offers great flexibility in terms of addressing end users. For example, the identity assurance level of end users registered with Freja eID can vary. If the user has followed an entry-level registration flow, their identity will be assured to level 2 within the scheme, also known as Freja eID Basic. At this level a user will have confirmed an email address and/or a mobile phone number, perfectly enough to allow, for example, login authentication in situations where an absolute identity is not of significance for the relying party Relying Party - knowing that the end user accessing a relying partyRelying Party's service is the same one that accessed the service a week ago without the hassle of teaching the end user an additional password is perfectly enough for many web-based services. However, if the end user opted for an extended registration process, their identity will be assured to level 3 within the scheme, also known as Freja eID+. The extended registration process involves, amongst other controls, vetting physical ID documents of the end user and face enrolment with Freja eID. Freja eID+ users can be referred to through their social security number (SSN). In Sweden, this would equate to having established a "personnummer" for the end user. Also, Freja eID+ users can be involved in interactions with web parties that involve login, but also legally binding signatures and identity assertion. If you want to find out more about identity assertion levels, please have a look at the Tillitsnivåer för elektronisk legitimation published by the Swedish e-Identification board. This document contains instructions for enabling Relying Party (RP) applications to use services offered by Freja eID. It is of a technical nature - if you are not a software architect or developer, it is probably the wrong document to read. Freja eID offers three services to RPs: Identity Assertion Service, Authentication service and Signing service. Our recommendation is to read the sections of interest to you in their entirety at least once. On later occasions, use the links to quickly navigate to the section of interest. Document Versions |
| Version | Date | Comment |
|---|
| 1.0 | 2017-04-26 | This document is a preliminary version. The content of this document is still under review and subject to change. |
| 2.0 | 2017-05-29 | Included Authentication Services. Changed examples to use signing certificate under Freja eID TEST root. |
| 2.1 | 2017-06-23 | Adjusted error codes to comply with conventions within other services. |
2.2 | 2017-06-30 | Adjusted error codes For easier integration, Freja eID also makes a distinction between Relying Parties, depending on the way they can integrate with us:
- Stand-alone RP - an RP that wants to integrate with us on their own behalf;
- Integrator RP - an RP that usually acts on behalf of their own customers, i.e. other organisations with their own branding, but can also integrate with us on their own behalf;
- Integrated RP - an RP which is not connected with Freja eID system directly, rather via the Integrator RP.
Read more about how Integrator and Integrated Relying Parties can integrate with Freja eID in Integrator Relying Party Management.
This document contains instructions for enabling Relying Party applications to use services offered by Freja eID. It is of a technical nature - if you are not a software architect or developer, it is probably the wrong document to read.
Freja eID offers three services to RPs: Identity Assertion Service, Authentication Service and Signing Service. Our recommendation is to read the sections of interest to you in their entirety at least once. On later occasions, use the links to quickly navigate to the section of interest.
Document Versions
| Version | Date | Comment |
|---|
| 1.0 | 2017-04-26 | This document is a preliminary version. The content of this document is still under review and subject to change. |
| 2.0 | 2017-05-29 | Included Authentication Services. Changed examples to use signing certificate under Freja eID TEST root. |
| 2.1 | 2017-06-23 | Adjusted error codes to comply with conventions within other services. |
| 2.2 | 2017-06-30 | Adjusted error codes for validation errors. Instead of generic error 1000 and list of specific errors, specific error is returned directly. |
| 2.3 | 2017-08-03 | Opaque data must be max128 characters long. Adjusted identity assertion error codes. |
| 2.4 | 2017-08-10 | Changed the URL for posting the response for identity assertion. |
| 2.5 | 2017-09-13 | Changed the JWS header value from x5c to x5t. |
| 2.6 | 2017-11-01 | Added support for requesting additional user attributes when initiating the authentication. |
| 3.0 | 2018-01-19 | Changed the endpoint URLs for all Authentication Services methods. Adjusted error codes in Authentication Services. Included Signature Services. |
| 4.0 | 2018-03-29 | Included Integrator Relying Party Management. Included Custom Identifier Management and updated the support for requesting additional user attributes when initiating the authentication accordingly. Added support for cancelling an authentication or a signing request. Added example requests for all methods in all the services. Updated the custom URL scheme for automatic launch of Freja eID app. |
| 4.1 | 2018-06-05 | Added support for returning two more user attributes in the Authentication Services - SSN (personal identity number) and integratorSpecificUserId (a unique user identifier, specific for a particular Integrator RP)
Additional instruction Added instructions on how to obtain client TLS/SSL certificate to access Freja eID services. |
Abbreviations
| 4.2 | 2018-07-23 | Added support for PHONE as userInfoType and Extended signature types (see Signature Services). Defined changes to the attributesToReturn parameter for returning attributes BASIC_USER_INFO and SSN in responses.
|
Abbreviations
| CA | Certificate Authority |
| CSR | Certificate signing requestSigning Request |
| eID | Electronic identificationIdentification |
| JSON | JavaScript Object Notation |
| JWS | JSON Web Signature |
| PKCS | Portable Symmetric Key Container |
| PKI | Public Key Infrastructure |
| REST | Representational State Transfer |
| RP | Relying Party |
| RSA (cryptosystem) | Rivest–Shamir–Adleman |
| SSL/TLS | Secure Sockets Layer/Transport Layer Security |
| SSN | Social security number (''perssonnummer'' in Sweden) |
Getting started
IN PROGRESS
About Freja eID environments
Freja eID system offers two environments:
- Test or Demo Environment, which is designed for testing purposes, it is intended to be used by Relying Parties during the process of integration with Freja eiD to test the integrated services.
- Production Environment, which is where the Freja eID services are actually available for business use and where the real-time staging of integrated services is executed.
Note that the Test Environment tries to resemble the Production Environment in all segments.
Before you begin
Test environment checklist
There are several technical requirements that must be in place before the integration with Freja eID can start. Before proceeding, you need to:
- Obtain an SSL/TLS client certificate providing you access to the Freja eID Test Environment. For more information, refer to the Certificates section.
- Import Freja eID Test root certificate as trusted into in the trust store of your application.
- Using Freja eID mobile application, register one or more users with the Freja eID Test infrastructure.
Production environment checklist
In order to use Freja eID in a production environment, you must fulfil the following:
- Sign a contract allowing your organisation to access the production Freja eID Authentication service.
- Provide Freja eID with a logo suitable to represent your organisation in the mobile application, as well as a display name, a URL and a short description. Please note that:
- The logo must be delivered in one of the vector file formats: AI (Adobe Illustrator Artwork), EPS (Encapsulated PostScript) or editable PDF (Portable Document Format). The preferable format is AI (filename extension is .ai).
- The display name is restricted to the maximum length of 20 characters and the description should not exceed 75 characters. The URL can be up to 100 characters long.
- Obtain an SSL/TLS client certificate providing you access to the Freja eID Production Environment. For more information, refer to the Certificates section.
- Import Freja eID Production root certificate as trusted into in the trust store of your application.
Certificates in Freja eIDFreja eID system requires the usage of SSL/TLS certificates for communication with Relying Party applications. The following certificates are used:
- Freja eID's server certificate:
- Freja eID Test root certificate
- Freja eID Production root certificate
- Relying Party's client certificate:
- Test client certificate
- Production client certificate
AdditionalyAdditionally, JWS certificates are used to digitally sign the results of authentication and signature requests.
Freja eID server certificate is used so that RPs can autheticate authenticate Freja eID as trusted in their environment. Freja eID's server certificate should be imported in the trust store of the RP's application. There are two server certificates which you need to use:
- Freja eID Test root certificate, when you want to start the integration in the Test Environment
- Freja eID Production root certificate, when you want to execute your integration in the Production Environment
Below are Freja eID's Test and Production server SSL root certificates, PEM encoded:
| Test server SSL root certificate | Production server SSL root certificate |
|---|
| | |
Client certificate
As mentioned before, to access and use Freja eID services, you need to obtain a client SSL/TLS certificate. Two client certificates are needed, one for access to the Testing Environment and one for access to the Production Environment. Client certificate autheticates your application when it tries to communicate with Freja eID services. Additionally, Freja eID uses your Client certificate to identify you in its system when you try to send an authentication or sigining request.
The following section provides you with instructions on how to generate an SSL/TLS key and a certificate signing request (CSR), which you can then send to Freja eID partner support to provide you with the ready-made client certificate. It also documents how to create a PKCS#12 file.
| Note |
|---|
For this purpose, we used OpenSSL, an open-source criptography and SSL/TLS toolkit. For more information about OpenSSL, please refer to their official website. Of course, you can use any other CSR generator. |
What is an SSL/TLS key and what is it used for?
The SSL/TLS key is a part of the Public Key Infrastructure (PKI) that is generally used in case of SSL/TLS certificates. A Public Key Infrastructure assumes asymmetric encryption, where two types of keys are used: a Private Key and a Public Key (included in an SSL/TLS certificate). The private key is based on the RSA algorithm and is used for authentication and the establishment of an SSL/TLS session. Since encrypted data transmission takes too much time in case of asymmetric encryption, this kind of encryption is only used for a secure exchange of the symmetric key, which is used for actual transmitted data encryption and decryption.
What is a certificate signing request (CSR)?
A certificate signing request (also CSR or certification request) is a block of encoded text that is given to a certificate authority (CA) when applying for an SSL/TLS certificate. It is usually generated on the server where the certificate will be installed on and contains information that will be included in the certificate, such as the organisation name, common name (domain name), locality and country. It also contains the public key that will be included in the certificate. The private key is usually created at the same time as the CSR, thus making a key pair. A CSR is generally encoded using ASN.1, according to the PKCS #10 specification.
Distinguished name
SSL/TLS certificates contain identifying information, such as the qualified domain name used for DNS lookups of your server (also called Common Name), your organisation or company name and location information. This information is called the certificate's Distinguished Name. When generating a CSR on your server, you are asked to enter the Distinuguished Name, which uniquely identifies your server.
This is an example list of required fields for the Distinguished Name (i.e. Subject) used when generating a CSR request for a Freja eID Relying Party named "ACME AB":
| DN field | Name | Explanation | Example |
|---|
| CN | Common Name | (Optional) Function qualifier, if required. | Document signing service |
| OU | Organisational Unit | (Optional) Internal organisational qualifier, if required. | Production |
| O | Organisation Name | Legal name of the organisation, as registered with the company register of the country it operates in. | ACME AB |
| OI | Organisational identifier | Organisational number, as registered with the company register of the country it operates in. | 556677-8888 |
| C | Country | The two-letter ISO abbreviation of the country the company operates in. | SE |
| Note |
|---|
The following characters cannot be used in the Organization Name or the Organizational Unit: < >~ ! @ # $ % ^ * / \ ( ) ?.,& |
Client certificate generation - Step-by-step guide
Launch Open SSL (preferably on the production server) and generate your private key with the genrsa command (see below). Command arguments are the location and file name where you wish to store your key and the key strength (with minimum value of 2048 bits). You will also be prompted to choose a secure passphrase for the key.
| Code Block |
|---|
openssl genrsa -F4 -aes256 -out <PATH_TO_YOUR_PRIVATE_KEY>.key 2048 |
| Warning |
|---|
| title | Security recommendations |
|---|
|
As the security relies on the integrity and security of this private key, it is the best practice to generate the key on the production system itself and also to make sure that this key is protected duly against unauthorised attacks by limiting access to thekeyfileitself. Once the PKCS#12 file has been generated, the key file can be removed or stored securely offline for backup purposes. |
Next, generate the CSR using the key generated in the step 1 with the following command and put it in a file.
| Code Block |
|---|
openssl req -new -subj "/C=SE,2.5.4.97=556677-8888,OU=Production,O=ACME AB,CN=Document signing service" -key <PATH_TO_YOUR_PRIVATE_KEY>.key -out <PATH_TO_YOUR_CSR>.csr |
Compress the file with ZIP/gZIP and email it to partnersupport@frejaeid.com. After the certificate is issued by the Freja eID Support, you will receive a ZIP file with your new certificate, along with required Freja eID CA certificates.
| Filename | Description | Distinguished Name | Issuer |
|---|
| Freja eID Production Root.cer | Freja eID's offline root certificate | CN = Freja eID Root CA v1 OU = Production O = Verisec Freja eID AB 2.5.4.97 = 559110-4806 C = SE | CN = Freja eID Root CA v1 OU = Production O = Verisec Freja eID AB 2.5.4.97 = 559110-4806 C = SE |
| Freja eID Production Issuing CA.cer | Freja eID's Issuing Certificate Authority | CN = Freja eID Issuing CA v1 OU = Production O = Verisec Freja eID AB 2.5.4.97 = 559110-4806 C = SE | CN = Freja eID Root CA v1 OU = Production O = Verisec Freja eID AB 2.5.4.97 = 559110-4806 C = SE |
| Freja eID Production Certificates.pem | Freja eID certificate chain. Contains booth root and CA certificates | | |
| <YOUR CERTIFICATE>.cer | Your relying party issued certificate | CN = Document signing service OU = Production O = ACME AB 2.5.4.97 = 556677-8888 C = SE | CN = Freja eID Issuing CA v1 OU = Production O = Verisec Freja eID AB 2.5.4.97 = 559110-4806 C = SE |
Generate the PKCS#12 keystore file with the following command and choose a secure passphrase:
| Code Block |
|---|
openssl pkcs12 -aes256 -CAfile "Freja eID Production Certificates.pem" -export -in <YOUR CERTIFICATE>.cer -inkey <YOUR_PRIVATE_KEY>.key -out <YOUR_KEYSTORE>.pfx |
| Warning |
|---|
| title | Security recommendations |
|---|
|
As the security relies on the integrity and security of this keystore, create it on the production system and protect it the production system itself and also make sure that this key is protected duly against unauthorised attacks by limiting access to the keystore file itself. |
Verify connectivity against production with the following command:
| Code Block |
|---|
openssl s_client -verify_return_error -CAfile "Freja eID Production Certificates.pem" -export -in <YOUR CERTIFICATE>.cer -inkey <YOUR_PRIVATE_KEY>.key -connect services.prod.frejaeid.com |
| Warning |
|---|
|
Once connectivity has been verified, files from the ZIP file should be deleted to avoid misunderstandings. |
| Anchor |
|---|
JWS | JWS | JWS certificateFreja eID uses JWS to validate end users' signatures. Signatures created by the end users are PKI-based and therefore non-repudiable. Upon completion of the signature by the end user, the Relying Party receives a JWS structure containing the data that was presented to the user, as well as evidence that the Freja eID infrastructure has validated the signature.
JSON Web Signature (JWS) represents digitally signed content using JSON data structures and BASE64URL encoding. JWS has the following structure:
- JOSE Header
- JWS Payload
- JWS Signature
There are two different serializations for JWSs: a compact, URL-safe serialization called the JWS Compact Serialization and a JSON serialization called the JWS JSON Serialization. In both serializations, the JWS Protected Header, JWS Payload, and JWS Signature are BASE64URL encoded.
In Freja eID, the JWS Compact Serialization is used and a JWS is represented as the concatenation:
BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)
Example JWS signature:
{"userInfoType":"EMAIL","userInfo":"joe.black@verisec.com","minRegistrationLevel":"BASIC","title":"Sign transaction","confidential":false,"expiry":1517526000000,"dataToSignType":"SIMPLE_UTF8_TEXT","dataToSign":"{\"text\":\"VGhpcyBpcyBhIHRleHQgZm9yIHNpZ24gdHJhbnNhY3Rpb24u\"}","signatureType":"SIMPLE"}
| Test JWS certificate | Production JWS certificate |
| | |
Samples REMOVE THIS SECTION?
There are several examples where the data has been signed using RSA keys and certificates below. In all cases, the private key corresponding to the following certificate chain has been used:
| Certificate | Details |
|---|
End-entity (for signing key) | Subject: CN=Documentation and Demo, OU=Test, O=Verisec Freja eID AB, OID.-----BEGIN CERTIFICATE-----
MIIGMzCCBBugAwIBAgIUPB4rUqFFiG6g67a+cLCBCuTkxGQwDQYJKoZIhvcNAQEL
BQAwUTELMAkGA1UEBhMCU0UxEzARBgNVBAoTClZlcmlzZWMgQUIxEjAQBgNVBAsT
CUZyZWphIGVJRDEZMBcGA1UEAxMQUlNBIFRlc3QgUm9vdCBDQTAeFw0xNzA1MTAx
NDI2MDBaFw00NzA1MTAxNDI2MDBaMFExCzAJBgNVBAYTAlNFMRMwEQYDVQQKEwpW
ZXJpc2VjIEFCMRIwEAYDVQQLEwlGcmVqYSBlSUQxGTAXBgNVBAMTEFJTQSBUZXN0
IFJvb3QgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC6n6IvJcOI
y9y4x4YZlcDYWGANZn/58aQq/+q/2IOheqH7pfqf00FrZmTFzXQTI4koPUOpagYM
ESG6MLlgW7akCnA3V5duEvGBJgAR6FldaiwdHMqWBKLb5pvoC2/uczSNie+pEidQ
uj+Oh5MwUCJWx4n2fLoJMTP4Lb1nxFQXzCjRMWJ1w3pM+3mDYJzvLFhV2Ur7QBAd
JjGGPCprDdREfzanm7Jg5mFtdtbMPPobMVDKRiCvfXLavE4UeupJF2Rdg530tpaJ
Mb6m++OsFMN4sHq0HUYiYIwetdmxY3W2dpKJjmL7pPPprcpnHqci9a3N32ajclpV
Z7c0jfuwCwk+6EFYRNmCkKEkMrSe8wr8tuH4FYwhTQCsFQeAWUaWzSl29Ielmx38
Ot+g3aUw8LZltZzMYhak257bx4Lqfr23edjz2g45/DEk5H2/zsvEGnwq73xtpAJZ
rZHSqgugwPqLhCxKs93abuShMas92CL7juAp4FjYzjBS85qQnHhxVFziGoyvtUU3
YS6ZNae96KbgW7Kjd72i/wfUNJKdF2QAKWIJYL80bQ9m2w+sL6TNd/tRG3OXWJHD
prKRTYKiW2nZxDoX4ClsNMWj2iKPaGtbl6tmZpRLZtjs8s9lAiNBQd0XqtTsyyr/
3+8Afnhs+DG55A4/91DdaXlDA4UbpjZpDQIDAQABo4IBATCB/jAOBgNVHQ8BAf8E
BAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBAzCBuAYDVR0gBIGwMIGtMIGqBgUqAwQF
BjCBoDA4BggrBgEFBQcCARYsaHR0cHM6Ly9jcHMudGVzdC5mcmVqYWVpZC5jb20v
Y3BzL2luZGV4Lmh0bWwwZAYIKwYBBQUHAgIwWAxWVGhpcyBjZXJ0aWZpY2F0ZSBo
YXMgYmVlbiBpc3N1ZWQgIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgRnJlamEgZUlE
IFRFU1QgUG9saWN5IENvbnRyb2wwHQYDVR0OBBYEFMqw7LlXw5w9rTmKE/rwNbrs
DHeKMA0GCSqGSIb3DQEBCwUAA4ICAQBOGI2Y4uXQeAMSswESsIsbF4RlkvIQiGCd
kwt7OzpfiRcOQnkxm9rlpdPtC7MajVI6owtZwT6BSG0jmyUFLihp4VB02VM02xkc
YsSD/58V+Gf/1iEjgQgnNjz9Z5bURGUiPK9TWrchi7E2MLlySeHAEJUU1u5hwU0V
+0hQ4S+EEZBYfOV5WaoFma2YXFTSSCHtzmG+OMhItgevJFt+OLymOTewuF7v4vcP
PVyUB9iEgawEwpjJEBtaxkmIaJv4J/c92KKHcTKxr8EaPfOl4t3UCHmQLgnCEG/3
Hn6KgNsH6RCOmZojdTf5vwQZ2B7AcbVozU/noJZ1o6C4oRt5PkTEdSnAmX8pf4Mn
NXYmxPpXE7KlEazLx9poBGVobCn0X3F+1A5pEHfY8Oy/EOKc3+ZswW294AuWCs/n
HlamWPS+jqNKW3qjjNK6FZs72IECuf9OSN5BvDrUsW44b0Y6oGIUevOtexAXiBWV
SKT9GsojrlY36X0O3+lkkqtW4aea11qi3oGz+9iXcPQeeD7kgfkszSYKkn9WB1YT
j/lpZTlf9DlxA5++uu3Grpx7qRdClEbDf5Q2HLISWVwirocySGzh4wACFHi6iQjn
srnzHu968MtOnN6FQt9zPZxaRYrzLpV/9yyah9jYYuLFIGje+yzAn5M8ORV5p1At
FvjTRfH5oA==
-----END CERTIFICATE----- | -----BEGIN CERTIFICATE-----
MIIGKTCCBBGgAwIBAgIURVYm7hoZF4XSX/iKAN5xmB+3qF4wDQYJKoZIhvcNAQEL
BQAwdjELMAkGA1UEBhMCU0UxHTAbBgNVBAoTFFZlcmlzZWMgRnJlamEgZUlEIEFC
MRMwEQYDVQQLEwpQcm9kdWN0aW9uMR0wGwYDVQQDExRGcmVqYSBlSUQgUm9vdCBD
QSB2MTEUMBIGA1UEYRMLNTU5MTEwLTQ4MDYwHhcNMTcwODAxMTEzNzUwWhcNNDcw
ODAxMTEzNzUwWjB2MQswCQYDVQQGEwJTRTEdMBsGA1UEChMUVmVyaXNlYyBGcmVq
YSBlSUQgQUIxEzARBgNVBAsTClByb2R1Y3Rpb24xHTAbBgNVBAMTFEZyZWphIGVJ
RCBSb290IENBIHYxMRQwEgYDVQRhEws1NTkxMTAtNDgwNjCCAiIwDQYJKoZIhvcN
AQEBBQADggIPADCCAgoCggIBAKXB6WuJuqYlZQzRHWAxG4WI8WzwK0h8A4V7mL+x
LNH9dW5WykdKiC9WOrYq2bUYB5KJofMvsUMnmcbOmoTjNikBUvI88CZjinqpSd0O
kCEIHrEeNrk8C9tkNf6v879nsqr94k9uJj665OrRZinkTW+bxAWnYiEH1tNrc/Wj
nUWXR5pwZnDhO4m/fOHCR92LR5cP9zZ7DDBFPXqtTXURrXSyhoXn+/yKX/ubBeN4
OHorjS7cywEzyQkhvYSSIf1ypmDpRuBoL+sMKapCHgIrPcWeCMR0SHFaKxDe1bqL
Y59OKRcRBrm5Ec9RnJcnOT8DZoDQqWGDZ6GsSRuHlW5xkhhzrdlB6Lrw1avPcCvx
4/ZQTFLOZm+zpltUCG7Q/z9HzihGn0bqcrm1PYKQmRpTlwcqfgNGOConnNOkLW7h
+8szIR4xIpT6MroAZTrvwWi43Db35TQWZkPQ9NKKUmc98KN3cqcIvtjrLArK1nlS
9Juf30oQrU4lQbfod9NZYC/U03aonYd514wpz/mwtVFkY9zZfNfkfGmSwMGycexn
bBh5swIZYUvkmtdDZsHGXjJIsIFD4AI6NODRvyXvgLRDabvrqia22+cEvJ/eIQIK
hKm8Kvo3Y28g1oZPuePLZZkFeKHluBDsgBsJJspyIlYHS3s7YfBkhmzKDkH4JZaf
Pl/nAgMBAAGjga4wgaswDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8w
HwYDVR0jBBgwFoAUtHJ2xk4gUzOKnP0zaascRhQzY+MwSAYDVR0gBEEwPzA9Bggq
hXCBeQEBATAxMC8GCCsGAQUFBwIBFiNodHRwczovL3d3dy5mcmVqYWVpZC5jb20v
dGMvY2EuaHRtbDAdBgNVHQ4EFgQUtHJ2xk4gUzOKnP0zaascRhQzY+MwDQYJKoZI
hvcNAQELBQADggIBAGYhB+/Imju88U+TBz0ddO71aaO9otqvsAQFpVwXDERTqwG6
Z/3dXUZYWaP02CA6zRG7hy8o/EfkrDGyluNsUvN8XAskulCvhKNvQ86Rv1fEq6/v
kNeg+fhkF70R4NPAOmZm5uiho2QUT45gXPo16ICK9kCdLYdN6HrCK7/d+0bMDigH
moTlSvq8G50rpKcvxEBdwy7zAfYZ+p1B6gLV7ulUJot5fZ5+RG/mD3tmWHi2bQid
lsi3MM9Tpw1XWjimLSsdjXbV0LOzGVRcB4xbvDxM4OfR3zTCxJpdqE/9jLNVNr5O
IVqj3P+K3dU6ydj+RMjJILpRU+Po4YEhv32VFyITiX+n7GKXN2n7Sp13/6/UCgxe
cqBIuI+UK7F7c+ZKNY1RBh0uoIc/2hFkQNUz8R9LmTzex20Y0RhW9fq2cuNxp9vJ
IMPOiHsggGCn6hwf0RY94VDxGIhSAkzSVvfaiLZYejN2Xu/C2ym9wUd0QauBTpXO
mgIV38CMwmtbSKLxPqfEbgpk6+/An5HO3u4XoxKYroL8JuuKsZBxbQyiPmOZVeNg
uXExHmZhcayFRXMs4xJMXE1W1zj+zTsGa57QxFWfgH6FPfY2PG5Z/0MiBEMlS1V5
Q25JHHI64kWnkynGymYL2veqVOYxuJm2Jmzwkeequ5+pi814HCHGwjMpT60N
-----END CERTIFICATE----- |
Client SSL certificate
As mentioned before, to access and use Freja eID services, you need to obtain a client SSL/TLS certificate. Two client certificates are needed, one for access to the Testing Environment and one for access to the Production Environment. Client certificate authenticates your application when it tries to communicate with Freja eID services. Additionally, Freja eID uses your Client certificate to identify you in its system when you try to send an authentication or signing request.
The following section provides you with instructions on how to generate an SSL/TLS key and a certificate signing request (CSR), which you can then send to Freja eID partner support to provide you with the ready-made client certificate. It also documents how to create a PKCS#12 file.
| Note |
|---|
|
For this purpose, we used OpenSSL, an open-source cryptography and SSL/TLS toolkit. For more information about OpenSSL, please refer to their official website. Of course, you can use any other CSR generator. |
What is an SSL/TLS key and what is it used for?
The SSL/TLS key is a part of the Public Key Infrastructure (PKI) that is generally used in case of SSL/TLS certificates. A Public Key Infrastructure assumes asymmetric encryption, where two types of keys are used: a Private Key and a Public Key (included in an SSL/TLS certificate). The private key is based on the RSA algorithm and is used for authentication and the establishment of an SSL/TLS session. Since encrypted data transmission takes too much time in case of asymmetric encryption, this kind of encryption is only used for a secure exchange of the symmetric key, which is used for actual transmitted data encryption and decryption.
What is a certificate signing request (CSR)?
A certificate signing request (also CSR or certification request) is a block of encoded text that is given to a certificate authority (CA) when applying for an SSL/TLS certificate. It is usually generated on the server where the certificate will be installed on and contains information that will be included in the certificate, such as the organisation name, common name (domain name), locality and country. It also contains the public key that will be included in the certificate. The private key is usually created at the same time as the CSR, thus making a key pair. A CSR is generally encoded using ASN.1, according to the PKCS #10 specification.
Distinguished name
SSL/TLS certificates contain identifying information, such as the qualified domain name used for DNS lookups of your server (also called Common Name), your organisation or company name and location information. This information is called the certificate's Distinguished Name. When generating a CSR on your server, you are asked to enter the Distinguished Name, which uniquely identifies your server.
This is an example list of required fields for the Distinguished Name (i.e. Subject) used when generating a CSR request for a Freja eID Relying Party named "ACME AB":
| DN field | Name | Explanation | Example |
|---|
| CN | Common Name | (Optional) Function qualifier, if required. | Document signing service |
| OU | Organisational Unit | (Optional) Internal organisational qualifier, if required. | Production |
| O | Organisation Name | Legal name of the organisation, as registered with the company register of the country it operates in. | ACME AB |
| OI | Organisational identifier | Organisational number, as registered with the company register of the country it operates in. | 556677-8888 |
| C | Country | The two-letter ISO abbreviation of the country the company operates in. | SE |
| Note |
|---|
|
The following characters cannot be used in the Organization Name or the Organizational Unit: < >~ ! @ # $ % ^ * / \ ( ) ?.,& |
Client certificate generation - Step-by-step guide
Launch Open SSL (preferably on the production server) and generate your private key with the genrsa command (see below). Command arguments are the location and file name where you wish to store your key and the key strength (with the minimum value of 2048 bits). You will also be prompted to choose a secure passphrase for the key.
| Code Block |
|---|
openssl genrsa -F4 -aes256 -out <PATH_TO_YOUR_PRIVATE_KEY>.key 2048 |
| Warning |
|---|
| icon | false |
|---|
| title | Security recommendations |
|---|
|
As the security relies on the integrity and security of this private key, it is the best practice to generate the key on the production system itself and also to make sure that this key is protected duly against unauthorised attacks by limiting access to the key file itself. Once the PKCS#12 file has been generated, the key file can be removed or stored securely offline for backup purposes. |
Next, generate the CSR using the key generated in step 1 with the following command and put it in a file.
| Code Block |
|---|
openssl req -new -subj "/C=SE/2.5.4.97=556677-8888/OU=Production/O=ACME AB/CN=Document signing service" -key <PATH_TO_YOUR_PRIVATE_KEY>.key -out <PATH_TO_YOUR_CSR>.csr |
Compress the file with ZIP/gZIP and email it to partnersupport@frejaeid.com. After the certificate is issued by the Freja eID Support, you will receive a ZIP file with your new certificate, along with required Freja eID CA certificates.
| Filename | Description | Distinguished Name | Issuer |
|---|
| Freja eID Production Root.cer | Freja eID's offline root certificate | CN = Freja eID Root CA v1 OU = Production O = Verisec Freja eID AB 2.5.4.97 = 559110-4806 C = SE | CN = Freja eID Root CA v1 OU = Production O = Verisec Freja eID AB 2.5.4.97 = 559110-4806 C = SE |
| Freja eID Production Issuing CA.cer | Freja eID's Issuing Certificate Authority | CN = Freja eID Issuing CA v1 OU = Production O = Verisec Freja eID AB 2.5.4.97 = 559110-4806 C = SE | CN = Freja eID Root CA v1 OU = Production O = Verisec Freja eID AB 2.5.4.97 = 559110-4806 |
, L=Stockholm,
Issuer: CN=RSA TEST Issuing CA, OU=Test, O=Verisec Freja eID AB, OID.| Freja eID Production Certificates.pem | Freja eID certificate chain. Contains booth root and CA certificates | | |
| <YOUR CERTIFICATE>.cer | Your relying party issued certificate | CN = Document signing service OU = Production O = ACME AB 2.5.4.97 = |
55 9110-4806, L=Stockholm,
Base64 encoding:
| Code Block |
|---|
MIIEDTCCAvWgAwIBAgIUaKpKqy2TcGQeNQfUIZZD9jEzk5MwDQYJKoZIhvcNAQELBQAwgYMxCzA
JBgNVBAYTAlNFMRIwEAYDVQQHEwlTdG9ja2hvbG0xFDASBgNVBGETCzU1OTExMC00ODA2MR0wGw
YDVQQKExRWZXJpc2VjIEZyZWphIGVJRCBBQjENMAsGA1UECxMEVGVzdDEcMBoGA1UEAxMTUlNBI
FRFU1QgSXNzdWluZyBDQTAeFw0xNzA1MTcyMTE5MjNaFw0yMDA1MTcyMTE5MjNaMIGGMQswCQYD
VQQGEwJTRTESMBAGA1UEBxMJU3RvY2tob2xtMRQwEgYDVQRhEws1NTkxMTAtNDgwNjEdMBsGA1U
EChMUVmVyaXNlYyBGcmVqYSBlSUQgQUIxDTALBgNVBAsTBFRlc3QxHzAdBgNVBAMTFkRvY3VtZW
50YXRpb24gYW5kIERlbW8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBwTeuSLvrd
Ot8PJ3dfnlDS+tyTV5P35sm/UusrasPya0XUV3ctj8RxD2skLHYMZ10X87EvXBUw4FEKJ9YlwTO
A3UjZ3jXYX9TZlU/r0kZsvf4RBZO8MOje00oRRdx0go4L6SsTcoBQhgimkxBMcCY1aHqGDWMH61
DWxbepa/4Df6xuFegnMQp421mR2FFvRUi74HBCn35oVHZhYviWo7aTyPVFWd2wLN8GiV+jwunHU
Tdq61+f9pqhPJ0CM6VL9oAIl0D0LbDHbMUd4XuV1hB9wM5jKZaGQ3388rWs+9a83/BJjb1Wa5qD
9tICuIl8y/asOcQEuvX7fT7xyPwduvLAgMBAAGjdDByMA4GA1UdDwEB/wQEAwIGwDAMBgNVHRMB
Af8EAjAAMB8GA1UdIwQYMBaAFGp8ig+dcA4c2l8toDwmX4joFb+cMBIGA1UdIAQLMAkwBwYFKgM
EBQowHQYDVR0OBBYEFHgMFxByq68FGuntjoOa+TTXw/7/MA0GCSqGSIb3DQEBCwUAA4IBAQCV9g
0ZuHBWOIdqiLDss/kTr0Obaeap4DEF5uuuxqo2LKn0k1qGHh66uLdxS0i1nWyLZjphPi5l8CxxM
uhw0VZ90u4cguTYsUXy/s1dp12e48m7bVOz/SnghU8ag+2pAO1esSn3LJ0nOMlKe32IMuGLUXPR
ELG151DEam/3yWKeCtEkthPisDLUKHKoc9v6EQEo+IVkGluSWPaIpvdbJpISzW3c0m9Qzu+GqWj
A1ac/BzdHql0UyTIoXB6u2VVbuIAkTLVLeFWlnL6dOD4XoChN9LStqYKn4iovO+DA+AtQt8Q+4B
/8hQnMyNby0Zyn5BJw4dqDWCju5PIFct8IvYuu |
| Intermediate | Subject: CN=RSA TEST Issuing CA, OU=Test, O=Verisec Freja eID AB, OID.2.5.4.97=559 110-4806, L=Stockholm, C=SE
Issuer: CN=RSA Test Root CA, OU=Freja eID, O=Verisec AB, C=SE
Serial number: 7713823344a16064911fab8744c5e3f5b2a4815e
Valid from: Wed May 17 16:42:52 CEST 2017 until: Mon May 17 16:42:52 CEST 2027
Certificate fingerprints:
MD5: 82:D4:0F:A8:D5:10:A1:7D:B8:17:C3:11:5C:58:28:B9
SHA1: 50:B8:52:25:AA:72:8A:83:DB:76:60:85:CE:3B:C7:25:1F:9B:FD:E3
SHA256: 50:7D:1D:B0:91:76:02:0F:81:AF:06:C4:6D:CC:E5:65:E1:E4:39:B4:8E:
C3:3D:58:4D:DC:6D:4B:CF:5C:74:E2
Signature algorithm name: SHA256withRSA |
| Root | Subject: CN=RSA Test Root CA, OU=Freja eID, O=Verisec AB, C=SE
Issuer: CN=RSA Test Root CA, OU=Freja eID, O=Verisec AB, C=SE
Serial number: 3c1e2b52a145886ea0ebb6be70b0810ae4e4c464
Valid from: Wed May 10 16:26:00 CEST 2017 until: Fri May 10 16:26:00 CEST 2047
Certificate fingerprints:
MD5: 3E:93:03:ED:5B:EB:A2:E4:CD:73:EA:5A:7D:E7:01:39
SHA1: 59:F6:AB:50:1C:A4:4B:D6:D2:26:F7:44:77:11:C5:AF:D7:DA:A6:2E
SHA256: 8D:74:59:FD:04:60:24:2C:F0:3E:76:D5:F0:42:7E:A9:FE:33:DB:67:89:
D5:06:30:9A:AC:2C:97:DA:A6:E8:60
Signature algorithm name: SHA256withRSA |
All JWS headers are, therefore, identical and equal to the following:| Field | Value |
|---|
| Header | "alg":"RS256"
"x5t":"sH80ooAuG89kS13l_R_OvML3WZA" |
Base64 encoding of header | | Code Block |
|---|
eyJhbGciOiJSUzI1NiIsIng1dCI6InNIODBvb0F1Rzg5a1MxM2xfUl9Pdk1MM1daQSJ9
Serial number: 68aa4aab2d9370641e3507d4219643f631339393
Valid from: Wed May 17 23:19:23 CEST 2017 until: Sun May 17 23:19:23 CEST 2020
Certificate fingerprints:
MD5: E4:C7:7F:5C:6B:17:60:58:F8:BE:06:B0:73:CD:71:CF
SHA1: B0:7F:34:A2:80:2E:1B:CF:64:4B:5D:E5:FD:1F:CE:BC:C2:F7:59:90
SHA256: 8F:3D:CF:75:47:42:36:1A:19:76:86:52:FA:39:80:94:93:A0:C2:B4:5B:
50:7C:06:AC:DC:E5:E0:2A:40:29:5F
Signature algorithm name: SHA256withRSACN = Freja eID Issuing CA v1 OU = Production O = Verisec Freja eID AB 2.5.4.97 = 559110-4806 C = SE |
Generate the PKCS#12 keystore file with the following command and choose a secure passphrase:
| Code Block |
|---|
openssl pkcs12 -aes256 -CAfile "Freja eID Production Certificates.pem" -export -in <YOUR CERTIFICATE>.cer -inkey <YOUR_PRIVATE_KEY>.key -out <YOUR_KEYSTORE>.pfx |
| Warning |
|---|
| icon | false |
|---|
| title | Security recommendations |
|---|
|
As the security relies on the integrity and security of this keystore, create it on the production system and protect it the production system itself and also make sure that this key is protected duly against unauthorised attacks by limiting access to the keystore file itself. |
Verify connectivity against production with the following command:
| Code Block |
|---|
openssl s_client -verify_return_error -CAfile "Freja eID Production Certificates.pem" -export -in <YOUR CERTIFICATE>.cer -inkey <YOUR_PRIVATE_KEY>.key -connect services.prod.frejaeid.com |
| Warning |
|---|
|
Once connectivity has been verified, files from the ZIP file should be deleted to avoid misunderstandings. |
JWS certificate
Freja eID uses JWS to validate end users' signatures. Signatures created by the end users are PKI-based and therefore non-repudiable. Upon completion of the signature by the end user, the Relying Party receives a JWS structure containing the data that was presented to the user, as well as evidence that the Freja eID infrastructure has validated the signature.
JSON Web Signature (JWS) represents digitally signed content using JSON data structures and BASE64URL encoding. JWS has the following structure:
- JOSE Header
- JWS Payload
- JWS Signature
There are two different serializations for JWSs: a compact, URL-safe serialization called the JWS Compact Serialization and a JSON serialization called the JWS JSON Serialization. In both serializations, the JWS Protected Header, JWS Payload, and JWS Signature are BASE64URL encoded.
In Freja eID, the JWS Compact Serialization is used and a JWS is represented as the concatenation:
BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)
Example JWS signature:
{"userInfoType":"EMAIL","userInfo":"joe.black@verisec.com","minRegistrationLevel":"BASIC","title":"Sign transaction","confidential":false,"expiry":1517526000000,"dataToSignType":"SIMPLE_UTF8_TEXT","dataToSign":"{\"text\":\"VGhpcyBpcyBhIHRleHQgZm9yIHNpZ24gdHJhbnNhY3Rpb24u\"}","signatureType":"SIMPLE"}
| Test JWS certificate | Production JWS certificate |
|---|
-----BEGIN CERTIFICATE-----
MIIEETCCAvmgAwIBAgIUTeCJ0hz3mbtyONBEiap7su74LZwwDQYJKoZIhvcNAQEL
BQAwgYMxCzAJBgNVBAYTAlNFMRIwEAYDVQQHEwlTdG9ja2hvbG0xFDASBgNVBGET
CzU1OTExMC00ODA2MR0wGwYDVQQKExRWZXJpc2VjIEZyZWphIGVJRCBBQjENMAsG
A1UECxMEVGVzdDEcMBoGA1UEAxMTUlNBIFRFU1QgSXNzdWluZyBDQTAeFw0xNzA3
MTIxNTIwMTNaFw0yMDA3MTIxNTIwMTNaMIGKMQswCQYDVQQGEwJTRTESMBAGA1UE
BxMJU3RvY2tob2xtMRQwEgYDVQRhEws1NTkxMTAtNDgwNjEdMBsGA1UEChMUVmVy
aXNlYyBGcmVqYSBlSUQgQUIxDTALBgNVBAsTBFRlc3QxIzAhBgNVBAMTGkZyZWph
IGVJRCBURVNUIE9yZyBTaWduaW5nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAgMINs87TiouDPSSmpn05kZv9TN8XdopcHnElp6ElJLpQh3oYGIL4B71o
IgF3r8zRWq8kQoJlYMugmhsld0r0EsUJbsrcjBJ5CJ1WYZg1Vu8FpYLKoaFRI/qx
T6xCMvd238Q99Sdl6G6O9sQQoFq10EaYBa970Tl3nDziQQ6bbSNkZoOYIZoicx4+
1XFsrGiru8o8QIyc3g0eSgrd3esbUkuk0eH65SeaaOCrsaCOpJUqEziD+el4R6d4
0dTz/uxWmNpGKF4BmsNWeQi9b4gDYuFqNYhs7bnahvkK6LvtDThV79395px/oUz5
BEDdVwjxPJzgaAuUHE+6A1dMapkjsQIDAQABo3QwcjAOBgNVHQ8BAf8EBAMCBsAw
DAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBRqfIoPnXAOHNpfLaA8Jl+I6BW/nDAS
BgNVHSAECzAJMAcGBSoDBAUKMB0GA1UdDgQWBBT7j90x8xG2Sg2p7dCiEpsq3mo5
PTANBgkqhkiG9w0BAQsFAAOCAQEAaKEIpRJvhXcN3MvP7MIMzzuKh2O8kRVRQAoK
Cj0K0R9tTUFS5Ang1fEGMxIfLBohOlRhXgKtqJuB33IKzjyA/1IBuRUg2bEyecBf
45IohG+vn4fAHWTJcwVChHWcOUH+Uv1g7NX593nugv0fFdPqt0JCnsFx2c/r9oym
+VPP7p04BbXzYUk+17qmFBP/yNlltjzfeVnIOk4HauR9i94FrfynuZLuItB6ySCV
mOlfA0r1pHv5sofBEirhwceIw1EtFqEDstI+7XZMXgDwSRYFc1pTjrWMaua2Uktm
JyWZPfIY69pi/z4u+uAnlPuQZnksaGdZiIcAyrt5IXpNCU5wyg==
-----END CERTIFICATE----- | -----BEGIN CERTIFICATE-----
MIIEvTCCAyWgAwIBAgIUZBsJTBnWAwJ2kWEgFlvLkadSONAwDQYJKoZIhvcNAQEL
BQAweTELMAkGA1UEBhMCU0UxFDASBgNVBGETCzU1OTExMC00ODA2MR0wGwYDVQQK
ExRWZXJpc2VjIEZyZWphIGVJRCBBQjETMBEGA1UECxMKUHJvZHVjdGlvbjEgMB4G
A1UEAxMXRnJlamEgZUlEIElzc3VpbmcgQ0EgdjEwHhcNMTcwODAyMTYyODIzWhcN
MjAwODAyMTYyODIzWjB6MSEwHwYDVQQDExhGcmVqYSBlSUQgSldTIFNpZ25pbmcg
djExFDASBgNVBGETCzU1OTExMC00ODA2MRMwEQYDVQQLEwpQcm9kdWN0aW9uMR0w
GwYDVQQKExRWZXJpc2VjIEZyZWphIGVJRCBBQjELMAkGA1UEBhMCU0UwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7y2YjMYwNq5j09dQQp293NdBskxEL
puPUEYE6DD0m3HvWZq3bJqaVuav9NSSXqevtuBm0BUpEFFDARief6bgozJY+WGkP
tURLjCoroHbkjA9jeX6Z1BpFdi/zOOlg4i19u0QxznBTTes41UT5uFwIrS2yq867
o8kczUs6RCGdw30Ikysm3t/zWWjHu6y4BTkMWvxLMQZFpuAad/vEjG+y0/+3oxzl
3CH9HhwQtT4xPH3UpcFw4nKt6hTXQDNSQUEQTQbB86Z6sAEPxwnvL/SZS7cmARw6
CeDX+fvJv6sXwBjsNGL7B3YMib/1rBPKE2jskqMrF1hYuqRd/xi1jjFRAgMBAAGj
gbswgbgwDgYDVR0PAQH/BAQDAgbAMAwGA1UdEwEB/wQCMAAwWAYIKwYBBQUHAQEE
TDBKMEgGCCsGAQUFBzAChjxodHRwczovL3d3dy5mcmVqYWVpZC5jb20vdGMvY2Vy
dHMvZnJlamFlaWRfaXNzdWluZ19jYV92MS5jZXIwHwYDVR0jBBgwFoAUED8kN9o6
iEfwKOPN0xXwS6n2sVAwHQYDVR0OBBYEFJJt+ukaSQCnRFQpuEVrwG9c2EDNMA0G
CSqGSIb3DQEBCwUAA4IBgQAZiytgukQ4ka0VXnkDbtEiF8LluPz3pFIZrXJTllmF
EGYT3RSb4e52wKkEzPZG0z0JlpjeZHeU8LOyKDe3jqDMSc7N0t5mA25GgjNOGYme
JZYsFlZZrP6jmNTSfFJKpy3Uvoj7+CKt+0qei4CB/RPscRrGHDMyc8lLVH6Bh1oI
9NRMB1m23AWFEXEKtQJUMTBOcMVcUaHm2jjZvagLf/SJ+jU1VFc/OzJYud8IAL6J
EfWn4deY5qUEJTQrLskF2jyL/5VTHJsk8DC90wjt0lJFX7nKS/MqCr+0yEIHIwST
APa/7M16YKBkEdQidcu2uYp4GHZCcB72XDxXO8JtL62OPTS80HgA9kMb5MZdJeo2
awGyCBVPbZXAgfypr6pGQafMFkZoBzp9N1z+YGEJqEAFgljS5vNtEUGsPiRe8DUP
A59tnAEF09W7HQDw3hSabyYNGuMndtV575CvyXFBOH4VM6bda+MC+8oy0SyubD/h
daqqd+KNF8QMZrDM6RqcWao=
-----END CERTIFICATE----- |
Authentication and Signature services are exposed through a RESTful API. This section presents information common to both services. Firstly, the following applies to HTTP response codes.
| |
|---|
| 200 OK | Success, additional information is available in the body. |
| 204 No Content | Success, no additional information is available in the body. |
| 400 Bad Request | The request is malformed. For example, the body cannot be parsed. |
| 404 Not Found | Requested resource does not exist. |
| 410 Gone | Requested resource is no longer available. For example, an obsolete API version. |
| 422 Unprocessable Entity | Validation or processing errors. Additional information is available in the body. If the input is corrected, the request can be resubmitted. |
| 500 Internal server error | The request, although probably OK, could not be processed due to an internal server error. Repeating the request is not recommended, the application should return a sensible error message to the end user. |
Where errors need to be conveyed (for example, in the case of HTTP 422 code for a RESTful API), the following structure is returned in the body. Note that the code and error message are always present in a case of error.
| Code Block |
|---|
{
"code": "Integer with error code value",
"message": "Error description"
} |