In SAML metadata file there are several NameID format defined, for example:
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
Can anybody explain what are these used for? What are the differences?
Refer to Section 8.3 of this SAML core pdf of oasis SAML specification.
SP and IdP usually communicate each other about a subject.
That subject should be identified through a NAME-IDentifier , which should be in some format so that It is easy for the other party to identify it based on the Format.
All these
1.urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified [default]
2.urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
3.urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
4.urn:oasis:names:tc:SAML:2.0:nameid-format:transient
are format for the Name Identifiers.
The name format for a transient ID in SAML 1 is urn:mace:shibboleth:1.0:nameIdentifier and in SAML 2 is urn:oasis:names:tc:SAML:2.0:nameid-format:transient
Transient is for [section 8.3.8 of SAML Core]
Indicates that the content of the element is an identifier with
transient semantics and SHOULD be treated as an opaque and temporary
value by the relying party.
Unspecified can be used and it purely depends on the entities implementation on their own wish.
About this I think you can reference to http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html.
Here're my understandings about this,
with the Identity Federation Use Case to give a details for those concepts:
Persistent identifiers-
IdP provides the Persistent identifiers, they are used for linking to the local accounts in SPs, but they identify as the user profile for the specific service each alone. For example, the persistent identifiers are kind of like : johnForAir, jonhForCar, johnForHotel, they all just for one specified service, since it need to link to its local identity in the service.
Transient identifiers-
Transient identifiers are what IdP tell the SP that the users in the session have been granted to access the resource on SP, but the identities of users do not offer to SP actually. For example, The assertion just like “Anonymity(Idp doesn’t tell SP who he is) has the permission to access /resource on SP”. SP got it and let browser to access it, but still don’t know Anonymity' real name.
unspecified identifiers-
The explanation for it in the spec is "The interpretation of the content of the element is left to individual implementations". Which means IdP defines the real format for it, and it assumes that SP knows how to parse the format data respond from IdP. For example, IdP gives a format data "UserName=XXXXX Country=US", SP get the assertion, and can parse it and extract the UserName is "XXXXX".
It is just a hint for the Service Provider on what to expect from the NameID returned by the Identity Provider. It can be:
unspecified
emailAddress – e.g. john#company.com
X509SubjectName – e.g. CN=john,O=Company Ltd.,C=US
WindowsDomainQualifiedName – e.g. CompanyDomain\John
kerberos– e.g. john#realm
entity – this one in used to identify entities that provide SAML-based services and looks like a URI
persistent – this is an opaque service-specific identifier which must include a pseudo-random value and must not be traceable to the actual user, so this is a privacy feature.
transient – opaque identifier which should be treated as temporary.
1 and 2 are SAML 1.1 because those URIs were part of the OASIS SAML 1.1 standard. Section 8.3 of the linked PDF for the OASIS SAML 2.0 standard explains this:
Where possible an existing URN is used to specify a protocol. In the case of IETF protocols, the URN of the most current RFC that specifies the protocol is used. URI references created specifically for SAML have one of the following stems, according to the specification set version in which they were first introduced:
urn:oasis:names:tc:SAML:1.0:
urn:oasis:names:tc:SAML:1.1:
urn:oasis:names:tc:SAML:2.0:
Related
What are the use of these keycloak endpoints?
issuer: "http://localhost:8180/auth/realms/dev",
authorization_endpoint: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/auth",
token_endpoint: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/token",
introspection_endpoint: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/token/introspect",
userinfo_endpoint: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/userinfo",
end_session_endpoint: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/logout",
jwks_uri: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/certs",
check_session_iframe: "http://localhost:8180/auth/realms/dev/protocol/openid-connect/login-status-iframe.html"
I know that on the token_endpoint I can get an access token, but I have no idea about the rest. I can see the data if I open the links but I have no idea when to use any of these in my java application.
issuer - realm that issues an access_token
introspection_endpoint - checks validity of an access_token
userinfo_endpoint - accepts access_token & returns info about current logged user, that is clarified in MAPPER of client
end_session_endpoint - forces an access_token invalidation
More information about KeyCloak endpoints you can find on baeldung (parts 5.1-5.5)
Check OIDC discovery spec: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata
issuer
REQUIRED. URL using the https scheme with no query or fragment component that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from this Issuer.
authorization_endpoint
REQUIRED. URL of the OP's OAuth 2.0 Authorization Endpoint [OpenID.Core].
token_endpoint
URL of the OP's OAuth 2.0 Token Endpoint [OpenID.Core]. This is REQUIRED unless only the Implicit Flow is used.
userinfo_endpoint
RECOMMENDED. URL of the OP's UserInfo Endpoint [OpenID.Core]. This URL MUST use the https scheme and MAY contain port, path, and query parameter components.
jwks_uri
REQUIRED. URL of the OP's JSON Web Key Set [JWK] document. This contains the signing key(s) the RP uses to validate signatures from the OP. The JWK Set MAY also contain the Server's encryption key(s), which are used by RPs to encrypt requests to the Server. When both signing and encryption keys are made available, a use (Key Use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage. Although some algorithms allow the same key to be used for both signatures and encryption, doing so is NOT RECOMMENDED, as it is less secure. The JWK x5c parameter MAY be used to provide X.509 representations of keys provided. When used, the bare key values MUST still be present and MUST match those in the certificate.
registration_endpoint
RECOMMENDED. URL of the OP's Dynamic Client Registration Endpoint [OpenID.Registration].
scopes_supported
RECOMMENDED. JSON array containing a list of the OAuth 2.0 [RFC6749] scope values that this server supports. The server MUST support the openid scope value. Servers MAY choose not to advertise some supported scope values even when this parameter is used, although those defined in [OpenID.Core] SHOULD be listed, if supported.
response_types_supported
REQUIRED. JSON array containing a list of the OAuth 2.0 response_type values that this OP supports. Dynamic OpenID Providers MUST support the code, id_token, and the token id_token Response Type values.
response_modes_supported
OPTIONAL. JSON array containing a list of the OAuth 2.0 response_mode values that this OP supports, as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]. If omitted, the default for Dynamic OpenID Providers is ["query", "fragment"].
grant_types_supported
OPTIONAL. JSON array containing a list of the OAuth 2.0 Grant Type values that this OP supports. Dynamic OpenID Providers MUST support the authorization_code and implicit Grant Type values and MAY support other Grant Types. If omitted, the default value is ["authorization_code", "implicit"].
acr_values_supported
OPTIONAL. JSON array containing a list of the Authentication Context Class References that this OP supports.
subject_types_supported
REQUIRED. JSON array containing a list of the Subject Identifier types that this OP supports. Valid types include pairwise and public.
id_token_signing_alg_values_supported
REQUIRED. JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT]. The algorithm RS256 MUST be included. The value none MAY be supported, but MUST NOT be used unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow).
id_token_encryption_alg_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (alg values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT].
id_token_encryption_enc_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (enc values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT].
userinfo_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS [JWS] signing algorithms (alg values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT]. The value none MAY be included.
userinfo_encryption_alg_values_supported
OPTIONAL. JSON array containing a list of the JWE [JWE] encryption algorithms (alg values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT].
userinfo_encryption_enc_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (enc values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT].
request_object_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for Request Objects, which are described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. These algorithms are used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). Servers SHOULD support none and RS256.
request_object_encryption_alg_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (alg values) supported by the OP for Request Objects. These algorithms are used both when the Request Object is passed by value and when it is passed by reference.
request_object_encryption_enc_values_supported
OPTIONAL. JSON array containing a list of the JWE encryption algorithms (enc values) supported by the OP for Request Objects. These algorithms are used both when the Request Object is passed by value and when it is passed by reference.
token_endpoint_auth_methods_supported
OPTIONAL. JSON array containing a list of Client Authentication methods supported by this Token Endpoint. The options are client_secret_post, client_secret_basic, client_secret_jwt, and private_key_jwt, as described in Section 9 of OpenID Connect Core 1.0 [OpenID.Core]. Other authentication methods MAY be defined by extensions. If omitted, the default is client_secret_basic -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].
token_endpoint_auth_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported by the Token Endpoint for the signature on the JWT [JWT] used to authenticate the Client at the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods. Servers SHOULD support RS256. The value none MUST NOT be used.
display_values_supported
OPTIONAL. JSON array containing a list of the display parameter values that the OpenID Provider supports. These values are described in Section 3.1.2.1 of OpenID Connect Core 1.0 [OpenID.Core].
claim_types_supported
OPTIONAL. JSON array containing a list of the Claim Types that the OpenID Provider supports. These Claim Types are described in Section 5.6 of OpenID Connect Core 1.0 [OpenID.Core]. Values defined by this specification are normal, aggregated, and distributed. If omitted, the implementation supports only normal Claims.
claims_supported
RECOMMENDED. JSON array containing a list of the Claim Names of the Claims that the OpenID Provider MAY be able to supply values for. Note that for privacy or other reasons, this might not be an exhaustive list.
service_documentation
OPTIONAL. URL of a page containing human-readable information that developers might want or need to know when using the OpenID Provider. In particular, if the OpenID Provider does not support Dynamic Client Registration, then information on how to register Clients needs to be provided in this documentation.
claims_locales_supported
OPTIONAL. Languages and scripts supported for values in Claims being returned, represented as a JSON array of BCP47 [RFC5646] language tag values. Not all languages and scripts are necessarily supported for all Claim values.
ui_locales_supported
OPTIONAL. Languages and scripts supported for the user interface, represented as a JSON array of BCP47 [RFC5646] language tag values.
claims_parameter_supported
OPTIONAL. Boolean value specifying whether the OP supports use of the claims parameter, with true indicating support. If omitted, the default value is false.
request_parameter_supported
OPTIONAL. Boolean value specifying whether the OP supports use of the request parameter, with true indicating support. If omitted, the default value is false.
request_uri_parameter_supported
OPTIONAL. Boolean value specifying whether the OP supports use of the request_uri parameter, with true indicating support. If omitted, the default value is true.
require_request_uri_registration
OPTIONAL. Boolean value specifying whether the OP requires any request_uri values used to be pre-registered using the request_uris registration parameter. Pre-registration is REQUIRED when the value is true. If omitted, the default value is false.
op_policy_uri
OPTIONAL. URL that the OpenID Provider provides to the person registering the Client to read about the OP's requirements on how the Relying Party can use the data provided by the OP. The registration process SHOULD display this URL to the person registering the Client if it is given.
op_tos_uri
OPTIONAL. URL that the OpenID Provider provides to the person registering the Client to read about OpenID Provider's terms of service. The registration process SHOULD display this URL to the person registering the Client if it is given.
Additional OpenID Provider Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Session Management 1.0 [OpenID.Session].
Some data are optional/recommended only, so Keycloak doesn't provide all of them.
According to the SAML 2.0 specification, the NameQualifier attribute in the NameID element is "the security or administrative domain that qualifies the name. This attribute provides a means to federate names from disparate user stores without collision."
My question is: can the "disparate user stores" be within the same IDP? If so, given that the Format of the NameID will be urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, does the IDP have the right to send anything in the name qualifier as long as it is unique to each of its datastore?
Does this mean that in order for the SP (provided it receives requests from different IDPs) to achieve uniqueness, it has to consider the remote entity ID, NameQualifier and NameID value?
From http://saml.xml.org/assertions,
" Note that a SAML response could contain multiple assertions, although its more typical to have a single assertion within a response."
But I want to know some practical scenarios where multiple assertions are needed.
Assertions are claims made by the Identity Provider (IdP). An Attribute is contained in an AttributeStatement, so email address, first name, surname etc would be Attribute instances in an AttributeStatement contained in a single Assertion. Each Assertion needs a Subject and can be used for different things. Normally there is only one Assertion containing an AuthenticationStatement and an AttributeStatement containing Attribute instances.
One use case for multiple Assertion could be a claim about the Subject that is time limited differently from the Attribute list. e.g. perhaps some fact about the user that should only be relied on for a short period of time, defined by Conditions->NotBefore->NotOnOrAfter. Perhaps some authentication mechanism that only allows users to be authenticated at the IdP for a short period of time, compared to the longer period of time their Attribute list can be used for.
You can see a use case for multiple Assertion in a SAMLResponse here.
I need to authenticate a SAML Respone , The Identity Provider has provided a metadata file. What are the steps to verify the SAML Response against contents of metadata ?.
One common answer, based around most federated SAML systems, is that you need to use the public key from the metadata to verify the signed response. If verifying a signature with a public key is an unfamiliar concept, spend a little time reading around PKI or "public key infrastructure." Then you should move to the XML Signature Specification.
I note that CAS uses SAML2 but does not build its trust infrastructure on signatures but on whitelists of service providers who are allowed to present tokens.
If you are using the PKI trust model, the signature should be in the <ds:Signature> element. The metadata should contain the public key in the <KeyDescriptor> element, ideally with the attribute use = signing. See Section "5 SAML and XML Signature Syntax and Processing" of the SAML Core specification for more details.
Other security checks include:
Is there a "InResponseTo" attribute? From Core: "...it MUST be present and its value MUST match the value of the corresponding request's ID
attribute."
Is there a "Destination" attribute? From Core: "If it is present, the actual recipient MUST check that the URI reference identifies the location at which the message was received. If it does not, the response MUST be discarded. "
I'm working on implementing a web service that uses X509 certificates for authentication and authorization of the caller.
Is it proper to specify the entity type (i.e. "end user" or "device") as part of the subject name, with, say, OU RDN?
Is it proper to specify the identity of the entity as part of the subject name, with CN RDN?
Is the best place for the authorization tokens to be part of the X509.v3 extensions (I understand authorization info, like "have access to cookie jar", doesn't belong in subject name section)?
If I am to include custom extension values into the certificates, is the proper way to do so is to apply for an OID (through PEN), and create child OID(s) that designate authorization information, and use these OID(s) as OIDs for the extensions? If that's wrong for some reason, any pointers to how this should be done in a standard way, would be appreciated.
It is proper to specify the entity's identity in the Common Name (CN) field of the Subject Distinguished Name (DN).
For a user or device, it would be appropriate to also specify the Organization (O) and/or Organizational Unit (OU) to which they belong in the Subject DN. There is also the User ID (UID) component.
There is a standard profile of X.509 for authorization assertions specified in RFC 5755. An attribute certificate bears one or more attributes about an identity such at group membership, role, clearance level, etc, as well as referencing the public key certificate (that is, the usual kind of X.509 certificate) of the identity to which the authorization information applies.
This standardized approach avoids any need to devise custom X.509 extensions, and hence, apply for an official OID (which is just as well, because I don't know the "offical" procedure for this.)