| version: | 21.06.2020 |
|---|
MPASSid SAML 2.0 profile
SAML profile is used to ensure that all the identity provides and services in a trust network can interoperate with each other. This is achieved by defining a subset from a much larger SAML2 -stanard standard and specifying certain functionalities in greater detail. When all the services follow the same guidelines we can build a trust network with best possible operational reliability and predictability.
...
- NameIDFormat is transient, urn:oasis:names:tc:SAML:2.0:nameid-format:transient
- Authentication Request Binding is HTTP-Redirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
- Authentication Response Binding is HTTP-Post, urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Post
- Authenticatication requests must be signed
- Encryption of Assertions is recommended
- Registered SAML - endpoints must be protected by using SSL / TLS encryption and they have to be in FQDN-format
Public keys should be provided as self-signed X.509 certificates with RSA public keys minimal length of 2048 bits.
- Single logout service in not implemented.
- Supported attributes are maintained within MPASSid data-model.
...
https://wiki.oasis-open.org/security/FrontPage
https://kantarainitiative.github.io/SAMLprofiles/saml2int.html
MPASSid OIDC profile
When a service (relying party) wants to join MPASSid trust network using OIDC they must provide redirect URI:s, authentication method and authorization flow they want to use. Default authentication method is "client_secret_basic" and authorization flow is "code". If your application needs heightened security consider using public keys as an authentication method ("private_key_jwt") instead of shared secret. Using implicit flow is not recommended in MPASSid trust network.
Native apps such as mobile (Android/IOS) or SPA-solutions should use dedicated tools like AppAuth https://appauth.io/ or any other supported library which implements secure solution for authentication for example PKCE stanard standard https://oauth.net/2/pkce/
Information needed for authentication (such as public keys, when using "private_key_jwt"-method) must be send to the operator at address tuki@mpass.fi. In exchange operator will provide connection information to the relying party. This can be for example client_id and client_secret.
Other adjustments to the stanard standard are:
- Registered endpoints must be protected by using SSL / TLS encryption and they have to be in FQDN - format
Public keys should be provided as self-signed X.509 certificates with RSA public keys minimal length of 2048 bits.
- Single logout service in not implemented.
- Only openid and profile scopes are supported
- Dynamic registration is not supported
- Supported claims are maintained within MPASSid data-model.
...