Solved: Custom OSP Integration - Micro Focus Community

rrawson · ‎2019-08-02

Folks,

I have a simple developer question I am hoping someone might have thought through before.

If I wrote a custom JSP page and put it somewhere in the tomcat/webapps structure that requires authentication (say, /sspr/private/myCustom.jsp) how could such a page get (and display) the DN of the authenticated user?

Thanks
Rob

rrawson · ‎2019-08-05

I have a resolution functionally, it is not custom OSP Integration, but I can get what I need using SSPR

Once I have an SSPR authentication, running a JSP page that's within the /sspr/public space, I get a header that has the information I need in it. So it's actually a lot simpler than I thought, for this specific case.

I had tried this earlier but hadn't realized how bolluxed up my SSPR / OSP integration was. Once I fixed it, the solution became clear.

It would be great if MF documented with examples how to build your own app that leverages OSP, but that's a topic for another day.

View solution in original post

al_b · ‎2019-08-03

Hi Rob,

We use "custom" SSO method for a number of our apps and I believe, that this method can work for you.

1. User already logged to his Windows workstation and information about the logged user available thru WIA from IE, Chrome, FF

2. A number of JavaScript/Java/etc libraries can supply the same information.

We store NTLogon, Kerberos and other important AD information in eDirectory user custom attributes.

Thus, based on AD "whoami" information (from any domain/forest), we always know "logged" user info.

al_b · ‎2019-08-03

After an explanation of the basic idea, did search for "Tomcat Windows Integration" and immediately got How-to document.

https://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html

rrawson · ‎2019-08-03

I don't think this is what I am looking for. I can't rely on the Windows login for the users identity since what I need is their eDir LDAP DN as authenticated by OSP to sspr.

But I think I have found something that should work and I am trying to develop a test page now. I should be able to make a REST call to IDMProv and return a json with the DN in it.

https://www.netiq.com/documentation/identity-manager-47/identity_apps_admin/data/authentication-issues-troubleshooting.html

These are troubleshooting steps but happens to do just what I need. Right now in my lab I don't have a real cert so because of HSTS this won't work but I will fix that or shut it off and see if I can get this going.

al_b · ‎2019-08-03

>I don't think this is what I am looking for. I can't rely on the Windows login for the users identity since what I need is their eDir LDAP DN as authenticated by OSP to sspr.

Hi Rob,

This is exactly end result in my case: I use Windows logon info for initiate query to eDirectory and get correspondent eDirectory object.

rrawson · ‎2019-08-04

We cannot be certain that the Windows login is the same as the eDirectory login. I want the current OSP session's user DN (from eDirectory), not the AD user DN (based on the workstation login). Therefore this approach doesn't fit our use case.

I think I have a simple solution if I can just get past some issues in my development lab (the 4.7 server is using self-signed certs and I think thought was preventing my test javascript from running, but it seems to be happy with the cert now.

I created this HTML

</head>

And then this javascript as WhoAmI.js:

fetch('//idm2.lab.cisus.com:9443/IDMProv/rest/access/users/fullName')
.then(
function(response) {
if (response.status !== 200) {
console.log('Looks like there was a problem. Status Code: ' +
response.status);
return;
}

// Examine the text in the response
response.json().then(function(data) {
console.log(data);
});
}
)
.catch(function(err) {
console.log('Fetch Error :-S', err);
});

Calling my html file from a browser that is already logged in to OSP, I would hope to get something similar to this back in the console:

{"dn":"cn=mary,ou=users,o=data","surname":"Contrary"}

but instead I get this in my debugger in Firefox

Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified

al_b · ‎2019-08-04

Hi Rob,

I'm happy to hear that you found a solution.

>We cannot be certain that the Windows login is the same as the eDirectory login. I want the current OSP session's user DN (from eDirectory), not the AD user DN (based on the workstation login). Therefore this approach doesn't fit our use case

It looks like you still have some confusions related to my solution.

Maybe it is not applicable to your current case, but I will try to explain it again.

1. We have a user in eDirectory. eDir DN: cn=user1,ou=Staff,o=Org

2. User has accounts in 2 different AD domains (even with completely different name convention).

AD1 DN: cn=user1,cn=users,dc=AD1,dc=com, AD1 logon: AD1\user1

AD2 DN: cn=u1,cn=users,dc=AD2,dc=com, AD1 logon: AD2\u1

3. User object in eDirectory has information about AD logon names in the custom attribute NTLogonList. part of user LDIF:

dn: CN=user1,ou=Staff,o=Org
NTLogonList: AD1\user1
NTLogonList: AD2\u1

4. LDAP query to eDirectory with ANY of available AD logon names will return proper eDirectory DN

&(ntlogonlist=AD2\u1)(cn=A*)

Result: CN=user1,ou=Staff,o=Org

rrawson · ‎2019-08-04

In this case some users might not be IDM integrated at all. Just in eDirectory. No associations. This must work with sspr even if it is totally standalone.

My "solution" is not done it is still a work in progress, I am working through the sequence of calls now since I realized I probably can't pick up a session ID from an earlier request and just reuse it. It looks like I need to at least request a grant to get a token once I get a 401 which replies with a session ID, I think that's enough, and what I see is promising, but still working through the code

rrawson · ‎2019-08-05

I have a resolution functionally, it is not custom OSP Integration, but I can get what I need using SSPR

Once I have an SSPR authentication, running a JSP page that's within the /sspr/public space, I get a header that has the information I need in it. So it's actually a lot simpler than I thought, for this specific case.

I had tried this earlier but hadn't realized how bolluxed up my SSPR / OSP integration was. Once I fixed it, the solution became clear.

It would be great if MF documented with examples how to build your own app that leverages OSP, but that's a topic for another day.

View solution in original post

Custom OSP Integration

Identity Applications