According to the docs of Identity Server, there's always the following four claims provided in each token:
Issuer name - iss
Client ID - client_id
Lifetime - exp
Scope - nbf
Given the lifetime is computed as expiration occasion, I understand all of the codes except for the last one. What does the code "NBF" stand for?
I even checked the disambiguation on Wikipedia but there's nothing relating tokens at all.
Bonus question. What's the reason behind the codes being of different format? I can't help wondering why client_id isn't following the same pattern and set to cid. I sense some historical context...
Not before
That's what nbf means.
The usage of this claim is optional and it identifies the time before which the token must not be accepted.
See the definition from the RFC 7519:
4.1.5. "nbf" (Not Before) Claim
The nbf (not before) claim identifies the time before which the
JWT MUST NOT be accepted for processing. The processing of the
nbf claim requires that the current date/time MUST be after or
equal to the not-before date/time listed in the nbf claim.
Implementers MAY provide for some small leeway, usually no more
than a few minutes, to account for clock skew. Its value MUST be a
number containing a NumericDate value. Use of this claim is
OPTIONAL.
The lifespan of the token starts after the time stated in the nbf claim and ends at the time stated in the exp claim.
Addressing your bonus question:
It's important to highlight that nbf is a standard claim registered in IANA while client_id is not. But it doesn't prevent client_id to be used.
Claim names can be defined at will by those using JWTs. The claims defined in the RFC 7519, however, are intentionally short:
All the names are short because a core goal of JWTs is for the representation to be compact.
This document also states the following:
Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- that is, not to exceed 8 characters without a compelling reason to do so.
Related
nbf: Defines the time before which the JWT MUST NOT be accepted for processing
I found this definition about nbf in json web tokens. But still wondering what the usage of nbf is? Why we use this? Does it relate to the term of security?
Any idea would be appreciated.
It definitely is up to how you interpret the time.
One of possible scenarios I could make up is literally - when a token must last from some particular point in time til another point in time.
Say, you're selling some API or resource. And a client purchased access that lasts for one hour and the access starts tomorrow in the midday.
So you issue a JWT with:
iat set to now
nbf set to tomorrow 12:00pm
exp set to tomorrow 1:00pm
There is one more thing to add what #zerkms told, if you want the token to be used from now, then
nbf also need to be current time(now)
Otherwise you'll get error like the token cannot be used prior to this particular time.
It can be given a time of 3 seconds from time of creation to avoid robots and allow only humans users to access the API.
'nbf' means 'Not Before'.
If nbf=3000, then the token cannot be used before 3 seconds of creation. This makes a brute force attack nearly impossible.
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.
In the SAML2 specification there are several places in an assertion where it is possible to specify a lifetime.
The <SubjectConfirmationData> element contains a NotOnOrAfter attribute.
The <Conditions> element contains a NotOnOrAfter attribute.
The <AuthnStatement> element contains a SessionNotOnOrAfter attribute.
What is the meaning of each of them? How do they relate to each other?
Specifically, which of them must be checked when...
... consuming an incoming Saml2Response using Web SSO
... establishing an application session in the SP
... refreshing (extending) an application session in the SP
... forwarding an assertion to a web service, to act on behalf of the subject (as described by #Thuan)
... issuing a single logout request to the idp, to ensure that the idp still knows of the session?
Each of the NotOnOrAfters are described in the SAML2 core specification. I've included the parts that I can find that describes these attributes here.
SubjectConfirmationData/#NotOnOrAfter
A time instant at which the subject can no longer be confirmed. The time value is encoded in UTC, as described in Section 1.3.3.
Note that the time period specified by the optional NotBefore and NotOnOrAfter attributes, if present, SHOULD fall within the overall assertion validity period as specified by the element's NotBefore and NotOnOrAfter attributes. If both attributes are present, the value for NotBefore MUST be less than (earlier than) the value for NotOnOrAfter.
Conditions/#NotOnOrAfter
Specifies the time instant at which the assertion has expired. The time value is encoded in UTC, as described in Section 1.3.3.
The NotBefore and NotOnOrAfter attributes specify time limits on the validity of the assertion within the context of its profile(s) of use. They do not guarantee that the statements in the assertion will be correct or accurate throughout the validity period. The NotBefore attribute specifies the time instant at which the validity interval begins. The NotOnOrAfter attribute specifies the time instant at which the validity interval has ended. If the value for either NotBefore or NotOnOrAfter is omitted, then it is considered unspecified. If the NotBefore attribute is unspecified (and if all other conditions that are supplied evaluate to Valid), then the assertion is Valid with respect to conditions at any time before the time instant specified by the
NotOnOrAfter attribute. If the NotOnOrAfter attribute is unspecified (and if all other conditions that are supplied evaluate to Valid), the assertion is Valid with respect to conditions from the time instant specified by the NotBefore attribute with no expiry. If neither attribute is specified (and if any other conditions that are supplied evaluate to Valid), the assertion is Valid with respect to conditions at any time.
If both attributes are present, the value for NotBefore MUST be less than (earlier than) the value for NotOnOrAfter.
AuthnStatement/#SessionNotOnOrAfter
Indicates an upper bound on sessions with the subject derived from the enclosing assertion. The time value is encoded in UTC, as described in Section 1.3.3. There is no required relationship between this attribute and a NotOnOrAfter condition attribute that may be present in the assertion. It's left to profiles to provide specific processing rules for relying parties based on this attribute.
I cross-posted this question to the SAML-dev mailing list and got an answer from Scott Cantor, who has been an editor on the specifications.
The times in the <SubjectConfirmationData> signals for how long time assertion can be tied to the subject. In Web SSO where the subject confirmation method "bearer" is usually used, it means that within this time we can trust that the assertion applies to the one providing the assertion. The assertion might be valid for a longer time, but we must create a session within this time frame. This is described in the Web SSO Profile section 4.1.4.3. The times in <SubjectConfirmationData> must fall within the interval of those in <Conditions>.
The times in <Conditions> is the validity of the entire assertion. It should not be consumed after this time. There is nothing preventing a user session on an SP to extend beyond this point in time though.
SessionNotOnOrAfter is something completely different that is not directly related to the lifetime of the assertion or the subject. It is a parameter the idp can use to control how long an SP session may be. Please note that this parameter is defined that it SHOULD be handled by an SP according to the SAML2Core spec, but far from all SP implementations do. An example of an implementation that does is as usual Shibboleth, that always will respect the occurence of this parameter. When using Single Logout, this parameter is more critical, as it synchronizes the timeout of the session on both the SP and the Idp, to ensure that an SP does not issue a logout request for a session no longer known to the Idp.
In my opinion, only the authors of Saml2 specification can clearly answer this question. I also guess they can write a 10000-page book to explain about many "why" questions about the spec that people have asked for years. Anyway, based on my limited knowledge and on the use cases I have experienced with, my interpretation of those properties is:
Let's look at an example:
SSO: An SP receives an assertion from an IdP and log the user on.
Bootstrap token: The SP saves the assertion as a bootstrap token for later use.
The SP uses the bootstrap token to exchange for an ActAs token so that it can be used to access another web service. It will also cache the token for further uses to avoid having to exchange a new token often, as long as that token is still valid.
For (1), an assertion is valid when and only when both SubjectConfirmationData.NotOnOrAfter and Conditions.NotOnOrAfter are valid. Since the assertion is valid, the SP will create a login session for the user. How long the session should be is specified by the SessionNotOnOrAfter value.
How about 3? I would say the token is considered valid when Conditions.NotOnOrAfter is still valid. According to Scott Cantor: "Processing rules are specific to profiles and the context of use." Source: https://lists.internet2.edu/sympa/arc/mace-opensaml-users/2011-05/msg00007.html In that link they also discussed about the lifetimes of Subject and Conditions in which Conditions usually has longer lifetime than that of the Subject.
I'm in the midst of finalising the set of cmdlets for a server application. Part of the application includes security principal management and data object management, and "expiration" of both (timed and manual). After the expiration date, login and access for the security principal is refused and access to the data owned by that principal is optionally prevented (either immediately by deletion or as part of automatic maintenance by marking it as expired).
From the output of Get-Verb, I cannot see an obvious synonym for Expire, which is the most natural choice of verb for the action being undertaken here. Expire on a security principal expires the principal and may also expire all their stored data, while expire of a data object is restricted to that object.
Set- is already in use for both object types, and has a partial overlap in functionality (Expire- forces a date in the past, and removes data, while Set- will allow future or past dates but NOT remove the data).
In this fashion Expire is combining two operations (Set+Remove) and for data-security reasons, we wouldn't want to force separation into the two operations (that's already possible).
For this reason, I also consider that Disable- is not appropriate since it suggests the possibility of reversal with Enable-.
I also think Remove- by itself is inappropriate since there are data records specifically not deleted as part of the operation.
Unpublish seems very close at least for the data, but again it seems that the intent is for Unpublish and Publish to be paired, and in this case it would not be reversible. It also does not make sense when applied to the security principal.
So which (if any) standard verb would you expect to use, if you wanted to expire something?
Looking at the list of approved verbs, two jump out at me:
Deny (dn):
Refuses, objects, blocks, or opposes the state of a resource or process.
Revoke (rk): Specifies an action that does not allow access to a resource. This verb is paired with Grant.
I wouldn't worry too much if there is not a paired operation, since that happens with some of the built-in cmdlets. Stop-Computer, for example, has no paired Start-Computer. There is Remove-Variable, but no Add-Variable (there is New-Variable). I think that it is only important if a paired command exists that it is named consistently.
Another option may be to use something like a Set-ObjectExpiration/Get-ObjectExpiration especially, if it makes sense to want to query when objects are going to expire.
What about Invoke? It could be Invoke-ExpireAppObject Or something like that.
There really isn't an approved verb that fits your scenario based on MS reccomendations
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: