rrawson Honored Contributor.
Honored Contributor.
441 views

Custom OSP Integration

Jump to solution

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

 

Labels (1)
Tags (1)
0 Likes
1 Solution

Accepted Solutions
rrawson Honored Contributor.
Honored Contributor.

Re: Custom OSP Integration

Jump to solution

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

8 Replies
Knowledge Partner
Knowledge Partner

Re: Custom OSP Integration

Jump to solution

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.

0 Likes
Knowledge Partner
Knowledge Partner

Re: Custom OSP Integration

Jump to solution

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

 

0 Likes
rrawson Honored Contributor.
Honored Contributor.

Re: Custom OSP Integration

Jump to solution
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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Custom OSP Integration

Jump to solution

>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. 

0 Likes
rrawson Honored Contributor.
Honored Contributor.

Re: Custom OSP Integration

Jump to 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.

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

<html>
 <head>
  <meta http-equiv="Content-Security-Policy" content="default-src 'none'; img-src 'self';
script-src https://idm2.lab.cisus.com:9443/* 'self'; style-src 'self'">

  <meta charset="utf-8"/>
  <title>Who do I think you are?</title>
  <script src='WhoAmI.js'/>

 </head>

 <body>
 </body>
</html>

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

 

 

 

0 Likes
Knowledge Partner
Knowledge Partner

Re: Custom OSP Integration

Jump to solution

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

0 Likes
rrawson Honored Contributor.
Honored Contributor.

Re: Custom OSP Integration

Jump to solution
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 Honored Contributor.
Honored Contributor.

Re: Custom OSP Integration

Jump to solution

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

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.