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.
Related
RFC 7519 (https://datatracker.ietf.org/doc/html/rfc7519)
mentions a principal but doesn't define it.
What is a JWT Principal?
From Wikipedia:
A principal in computer security is an entity that can be authenticated by a computer system or network.
Let's consider an example where we're using JWT for user's authentication, then e.g. in the Subject Claim's definition from the RFC 7519:
The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
, principal is a specific user for whom a specific token was issued, and "sub" claim is some id of this user.
JOSE4J takes the jwks_uri as its starting point for JWT validation and I wondered whether it would be possible to support the Discovery Document as the starting point and JOSE4J would pick up the jwks_uri from there and then go the the JWKS key document to pick the public key matching the JWT at had through the kid. This way I only have to hardcode the discovery document uri in my code, as I worry a bit whether the jwks_uri might change without notice, the wellknow discovery document is to my knowledge fixed.
This is how it works now:
// The HttpsJwksVerificationKeyResolver uses JWKs obtained from the HttpsJwks and will select the
// most appropriate one to use for verification based on the Key ID and other factors provided
// in the header of the JWS/JWT.
HttpsJwksVerificationKeyResolver httpsJwksKeyResolver =
new HttpsJwksVerificationKeyResolver(https_jwks);
Maybe it would be nice to have the resolver recognize whether the discovery document uri is passed in or not and behave accordingly.
Thanks!
Jan
There's no direct support for it but you could implement your own VerificationKeyResolver with that logic (would likely use HttpsJwksVerificationKeyResolver internally). Or the application code could (periodically) pull the jwks_uri value from discovery document and use it to create the HttpsJwksVerificationKeyResolver.
If I have two JWTs, where their set of claims and headers are the same but the order they are stored in json is different, should they be considered equal?
Clarification:
I am aware that as a user of JWTs you should not need to compare them, but that is not what I am doing.
Say we have some jwt library, and you have some object that represents a JWT in it's decoded form. If we create an encoded JWT from our decoded JWT and then apply it to some function that returns once again the decoded JWT. Do we consider the two decoded JWTs to be equal if the order in which the claims or headers are stored in some collection has changed due to the decoding process?
Thinking more about this, perhaps it is wrong to store the headers and claims in a collection which has some notion of order? Using something like a set makes this problem disappear?
Depends on what you mean by 'different'. If the claims are the same then they are the same in the sense that the information transferred is equal. But if they both have the same signature then at least one will be invalid.
Also you shouldn't need to compare JWT claims at all. If you're storing the token and comparing the token given then you should revisit why you're using JWT over something like session.
JWT is designed to be independent. Because JWT tokens are claims based authentication the validation is done against the signature, not against anything on the server.
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. "
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: