[OPENAM-13978] Session Upgrade - AuthLevel format changes Created: 14/Nov/18 Updated: 15/Apr/20 Resolved: 18/Jan/19
|Affects Version/s:||5.5.1, 6.0.0, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11|
|Fix Version/s:||13.5.3, 14.1.2, 6.5.1, 6.0.1, 5.5.2, 7.0.0|
|Reporter:||Tasos Kampas||Assignee:||Lawrence Yarham|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Sprint:||AM Sustaining Sprint 57, AM Sustaining Sprint 58, AM Sustaining Sprint 59|
|Support Ticket IDs:|
|Needs QA verification:||
|Are the reproduction steps defined?:||
Yes and I used the same an in the description
AuthLevel format changes after a session upgrade.
Create 2 chains:
Insert AuthLevel in Session Property Whitelist Service
1. Log in using chainA, request a getSessionInfo:
2. Now re-login using the chanB as part of a session upgrade. Call the getSessionInfo:
Similar closed bugs:
We need AuthLevel format to be defined and consistent.
|Comment by Jonathan Thomas [ 11/Dec/18 ]|
I think this is more or less a duplicate of https://bugster.forgerock.org/jira/browse/OPENAM-9663 and assuming this change in format on session upgrade has been the been the case for some time.
To progress this we should decide whether we continue with
|Comment by Daniel Franke [ 07/Jan/19 ]|
nice try but:
|Comment by Peter Major [X] (Inactive) [ 07/Jan/19 ]|
Now to the constructive part:
I'm not sure I fully agree with the compatibility concerns from our part:
All in all, I think we should revisit our viewpoint on the AuthLevel property's format and consider making it consistent (if we want to go down on the Least Astonishment Principle path, the authentication level should be a number, not a realm qualified string).
NB: the REST endpoints should still return the AuthLevel as a string value (so "0"), because we don't really have session property schema/etc to describe the type of the property values.
|Comment by Jonathan Thomas [ 08/Jan/19 ]|
Based on last comments from Peter - we'll reopen and look into creating a standard format.
|Comment by Daniel Franke [ 08/Jan/19 ]|
The knowledge article says "authentication level".
You are right that the mentioned passage in authorization guide does not mention how AM handles it internally. But your glossary gives a clear definition for the term "authentication level" (https://backstage.forgerock.com/docs/am/6.5/authentication-guide/#openam-glossary):
"Positive integer associated with an authentication module, usually used to require success with more stringent authentication measures when requesting resources requiring special protection."
It also gives more explanation of the authentication level and explains how am handles it compares it etc. https://backstage.forgerock.com/docs/am/6.5/authentication-guide/#about-authentication-levels .
Also in authentication modules (auth nodes) you have to define and use it like an integer.
So inventing a new definition of the term for the kb article is a little bit childish especially as all other definitions and explanations are consistent to the definition in the glossary and there is now documentation of another definition/interpretation.
If I would be nitpicking I could say sorry, but it is defined as a positive integer and so string representation in json is not ok, but we are not in the kindergarten and string representation is ok for us (beside the fact that the definition for this is not absolutely clear and changing the getSessionInfo endpoint for this single session property would introtuce new bugs).
What is also not ok is that you are saying that the authentication level format is not defined at all and that you do not want to define it.
Especially as the way how to get it (kb-article) is defined and a definition of the "authentication level" is given (positive integer).
So In my opinion this here is a bug and also mentioned problem with authlevel in saml2 assetion (
But this are only my 2 cents.
I am happy that you decided to make it more consistent and hope that you will define the output of all endpoints (if you are still thinking that ther are different definitions of "authentication level"
|Comment by Peter Major [X] (Inactive) [ 08/Jan/19 ]|
My mistake, I don't really read the documentation.
|Comment by Tasos Kampas [ 15/Jan/19 ]|
The same is happening with the "AuthType", "Service" and "moduleAuthTime" session properties as well:
I will raise a different JIRA (OPENAM-14257)
|Comment by Ľubomír Mlích [ 22/Mar/19 ]|
Reproduced in AM 6.5.0 - I see
And in ForgeRock Access Management 6.5.1-RC2 Build 6e42f86d08 (2019-March-20 19:43) I see this as fixed, there is: