Highlighted
cnrossi Absent Member.
Absent Member.
821 views

Persist user data on authentication class and then inject it

Hi, I am writing a custom authentication class to require some additional info to users and then I have to inject that value on a custom header with an injection policy. This value should be valid only during the NAM Session so I don't want to persist it on a cookie or on the user store. Which strategy would you recommend to do that?

I have tried with the setPrincipalAttributes method at the Authentication Class but then the policy injects empty values. I set a session property but it is not accesible from the injection policy. I could use Cookies but I should play with the expiration time.

Thanks in advance,



Nicolás.
0 Likes
6 Replies
cnrossi Absent Member.
Absent Member.

Re: Persist user data on authentication class and then injec

Here is some additional info. Now I am setting a Liberty Custom Attribute because this is accesible in the Authentication Class and in the Injection Policy. It was suggested here.

I created a contract with my custom method together with a "Secure Name/Password Form" method. It works well if I first authenticate the user with a Secure Name/Password Form contract and then I try to access my new contract. If I try to access directly to my new contract it authenticates the user but fails saving the Liberty Profile with this error:

<amLogEntry> 2017-11-16T21:31:09Z SEVERE NIDS Application: Error setting principal attribute: An unexpected error occurred! System error code: NIDPLOGGING.200103003 </amLogEntry>

As I can see on the documentation this error code is "Unable to locate an identity id from the authentications available in the provided NIDPSession."

WSCMOPToken token = (WSCMOPToken)WSCToken.getToken(WSCMOPToken.OP_CS_CustomizableString1.getTokenUniqueId());

WSFModelEntry modelEntry = token.getModelEntry();
IDSISCommonAttributeElement data = modelEntry.getSchemaClassInstance();
if (data instanceof IDSISLeafAttributeElement)
((IDSISLeafAttributeElement)data).setText("custom value");

WSCMDataToken dataToken = new WSCMDataToken(token, data);
dataToken.setAllowOverride(true);

WSCResponse response = WSC.modifyData(m_Session, new WSCMDataToken[] {dataToken},m_Request.getLocale());


I guess the WSC.modifyData requires an active session and inside the doAuthenticate() method it is not created yet.

Thanks in advance for your help
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Persist user data on authentication class and then inject it

On 18-11-2017 12:44 AM, cnrossi wrote:
>
> Here is some additional info. Now I am setting a Liberty Custom
> Attribute because this is accesible in the Authentication Class and in
> the Injection Policy. It was suggested 'here'
> (https://forums.novell.com/showthread.php/490976-Set-the-value-of-a-shared-secret-in-a-custom-auth-class?p=2389463#post2389463).
>
> I created a contract with my custom method together with a "Secure
> Name/Password Form" method. It works well if I first authenticate the
> user with a Secure Name/Password Form contract and then I try to access
> my new contract. If I try to access directly to my new contract it
> authenticates the user but fails saving the Liberty Profile with this
> error:
>
> <amLogEntry> 2017-11-16T21:31:09Z SEVERE NIDS Application: Error setting
> principal attribute: An unexpected error occurred! System error code:
> NIDPLOGGING.200103003 </amLogEntry>
>
> As I can see on the documentation this error code is "Unable to locate
> an identity id from the authentications available in the provided
> NIDPSession."
>
> WSCMOPToken token =
> (WSCMOPToken)WSCToken.getToken(WSCMOPToken.OP_CS_CustomizableString1.getTokenUniqueId());
>
> WSFModelEntry modelEntry = token.getModelEntry();
> IDSISCommonAttributeElement data = modelEntry.getSchemaClassInstance();
> if (data instanceof IDSISLeafAttributeElement)
> ((IDSISLeafAttributeElement)data).setText("pepe");
>
> WSCMDataToken dataToken = new WSCMDataToken(token, data);
> dataToken.setAllowOverride(true);
>
> WSCResponse response = WSC.modifyData(m_Session, new WSCMDataToken[]
> {dataToken},m_Request.getLocale());
>
> I guess the WSC.modifyData requires an active session and inside the
> doAuthenticate() method it is not created yet.
>
> Thanks in advance for your help
>
>


Where are you getting the additional info from if I may ask?

--
Cheers,
Edward
0 Likes
cnrossi Absent Member.
Absent Member.

Re: Persist user data on authentication class and then injec

edmaa;2470301 wrote:
On 18-11-2017 12:44 AM, cnrossi wrote:
>
> Here is some additional info. Now I am setting a Liberty Custom
> Attribute because this is accesible in the Authentication Class and in
> the Injection Policy. It was suggested 'here'
> (https://forums.novell.com/showthread.php/490976-Set-the-value-of-a-shared-secret-in-a-custom-auth-class?p=2389463#post2389463).
>
> I created a contract with my custom method together with a "Secure
> Name/Password Form" method. It works well if I first authenticate the
> user with a Secure Name/Password Form contract and then I try to access
> my new contract. If I try to access directly to my new contract it
> authenticates the user but fails saving the Liberty Profile with this
> error:
>
> <amLogEntry> 2017-11-16T21:31:09Z SEVERE NIDS Application: Error setting
> principal attribute: An unexpected error occurred! System error code:
> NIDPLOGGING.200103003 </amLogEntry>
>
> As I can see on the documentation this error code is "Unable to locate
> an identity id from the authentications available in the provided
> NIDPSession."
>
> WSCMOPToken token =
> (WSCMOPToken)WSCToken.getToken(WSCMOPToken.OP_CS_CustomizableString1.getTokenUniqueId());
>
> WSFModelEntry modelEntry = token.getModelEntry();
> IDSISCommonAttributeElement data = modelEntry.getSchemaClassInstance();
> if (data instanceof IDSISLeafAttributeElement)
> ((IDSISLeafAttributeElement)data).setText("pepe");
>
> WSCMDataToken dataToken = new WSCMDataToken(token, data);
> dataToken.setAllowOverride(true);
>
> WSCResponse response = WSC.modifyData(m_Session, new WSCMDataToken[]
> {dataToken},m_Request.getLocale());
>
> I guess the WSC.modifyData requires an active session and inside the
> doAuthenticate() method it is not created yet.
>
> Thanks in advance for your help
>
>


Where are you getting the additional info from if I may ask?

--
Cheers,
Edward


Hi Edward, what do you mean? This is the code of our authentication class.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Persist user data on authentication class and then inject it

On 20-11-2017 8:54 AM, cnrossi wrote:

> Hi Edward, what do you mean? This is the code of our authentication
> class.
>
>


You are trying to store additional info on a user object. Where is this additional info being supplied from? NAM has the capability to query for
information about a user from LDAP, Databases and Webservices so perhaps you don't need to write your own code

--
Cheers,
Edward
0 Likes
cnrossi Absent Member.
Absent Member.

Re: Persist user data on authentication class and then injec

edmaa;2470407 wrote:
On 20-11-2017 8:54 AM, cnrossi wrote:

> Hi Edward, what do you mean? This is the code of our authentication
> class.
>
>


You are trying to store additional info on a user object. Where is this additional info being supplied from? NAM has the capability to query for
information about a user from LDAP, Databases and Webservices so perhaps you don't need to write your own code

--
Cheers,
Edward


As part of the authentication class the user has to select one of his AD groups and we store it on the session (or the Liberty Profile) to be available for injection to an application. There is no issue getting the groups or showing it to the user. The issue happens storing the value on the Liberty Profile.
0 Likes
seba4 Respected Contributor.
Respected Contributor.

Re: Persist user data on authentication class and then injec

Hi did you solve this? or how did you solve it? I have the same problem and i still didn't manage to fix it.

 

kind regards

Sebastjan

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.