Using System credentials in a CPIP connector
Fri, 2005-09-30 19:49 — webmonkey
Does anyone know how to use the system credentials in a CPIP connector?
Whe have a number of systems on campus including luminis that use the same credentials. I would like to create a connector that uses the luminis credentials to log into these external systems. I'm hoping that I do not need to create secret store entries for each connector that I want to build. Has anyone done this?
Thanks
DAVE
Hack Your Knowledge
Recent blog posts
- Luminis IV GCF Single Sign On with OSX=Failure PC=Working
- Cisco 4710 - Load Balancer
- First CPIP - ERROR
- Luminis Developer Job Available w/ Stable Organization
- Luminus Developer Job
- SSO to SSB mixed content error in IE
- Avoid email sending when add or delete user from group
- Luminis components
- Luminis 4 & Groupwise 7
- Luminis Developer Needed for Position w/ Stable Organization
Developer Links
Poll
What version of Lumins / OS are you running in production?
Luminis 4.x - Linux
21%
Luminis 4.x - Windows
8%
Luminis 4.x - Solaris
31%
Luminis 3.x - Windows
17%
Luminis 3.x - Solaris
19%
Luminis 3.x - Linux (if so - we need to talk) <G>
4%
We gave up on Luminis - I just like this site !
0%
Total votes: 52
- Login or register to post comments
- Older polls
Syndicate
one trick
Hi,
it's not all you need but this I discovered last week can help.
using generic connector with username ${_CPUSERNAME} rather than
${_USERNAME} means you don't need to do the cptool set user xyz ExterrnalAccount ... for each user. Maybe someone can improve on this.
R.
Here is something that would help
If you guys would like use credentials that user has logged into Luminis for CPIP authentication, here are the steps you need to do
1. Change XML configuration file and change USERNAME macro to CPUSERNAME that will send Luminis user id.
2. Execute command cptool sync password for the external system you are working on.
3. You will need to execute following command for all users
cptool set user username ExternalAccount='cpipname||'
As long as you have these options set your Luminis userid and password will be passed to External application.
Hope that helps.
Connector Setup
I don't believe you need Step 3 with this procedure.
The connector will use the CPUSERNAME (internal luminis userid) and the synched password (internal luminis password) for the connector. It then never looks at the ExternalAccount information since it has everything it needs. The ExternalAccount credentials are for systems that have different credentials. If you're fortunate enough to have a network like we do here - everything uses a central LDAP so blackboard, webmail, our old portal, luminis, custom secured web apps all have the same id/pw. So you can see why this is such a great find. The only ExternalAccount entry we have is for banweb - SSO to SelfService. Why that can't use LDAP I have no idea. I saw it in the WebTailor setup, but never was able to get it working right.
So what you need to do to set this up is basically step 1 and 2 above
1. CPUSERNAME : Edit your .properties and .xml files for your connector and change any instance of USERNAME to CPUSERNAME (should only be listed in one of the 2 files depending on the type of connector it is)
2. SYNC PASSWORD : The complete syntax is -
cptool sync password -add cpip externalsystemname
ie - cptool sync password -add cpip mcbb6
-Jon
Prompting for user credentials on first login
I've followed all the settings listed in this thread and it still asks for credentials on first attempt to the cpip. I am having to either do a cptool add ExternaAccount or manually enter the credentials at first login to get the cpip to auto login on subsequent requests. One question of clarification...does the cptool add ExternalAccount add the credentials to the secret store? Isn't the process described above suppose to bypass the need to define an ExternalAccount.
Some current settings we have
es.idm.createonlogin=1 => is this suppose to auto add the credentials to the secret store?
es.idm.sendcpuid=true
es.idm.autosync=true
es.idm.shortcircuitlogin=true
_CPUSERNAME substituted in .properties and .xml files
CPIP Application Filter [
System Name: idm
]
idm.cpipconnector.getconfig.sendlogin = true
idm.cpipconnector.getconfig.useSISCredentials = false
idm.cpipconnector.getconfig.usePDSCredentials = true
sync password and CPUSERNAME
To sync the password you do a cptool sync password:
$cptool sync password -add cpip CPIPNAME cpuid
And then, like Rich said, you have to use ${_CPUSERNAME} instead of ${_USERNAME} in the code for your CPIP. I don't exactly remember why, but that was the info I recieved from SCT support when I was trying to get our email working.
one more thing
I also forgot to mention that I have these settings in configman:
es.CPIPNAME.createonlogin=1
es.CPIPNAME.sendcpuid=true
es.CPIPNAME.shortcircuitlogin=true
Will this work for non
Will this work for non generic connector adapters?
Also, do I need to sync it after every user import?
The sync password command
The sync password command you only have to run once when you setup your CPIP. A user's external account will be created the first time they try to log into the external system, so I don't think it should have anything to do with user imports.
As far as non Generic Connector adapters... I'm not sure because I have not created any of these yet. I would be curious to know though.
I hope you're able to get everything setup :)
Christine
_CPUSERNAME / sync password
Christine - you rock !
I didn't know using that combination let you not have to create ExternalAccount entries. I tested this and it works great. I changed the _USERNAME to _CPUSERNAME and used an LDAP Browser to remove the cpip ExternalAccount entry and it worked great.
Thank you ! This will make things much easier now. I've been using sync password but I've also been creating ExternalAccount entries.
Wow, that's something they don't teach you in GCF class - go figure.
-Jon
GCF sync
Word up Jon, thats the beauty of this website. Today it's "GCF... the mysteries revealed"
Melissa, as far as the password goes... if you are sync'ing it then you can leave it blank and Luminis will use your system password. Otherwise, if you leave it black without sync'ing it, Luminis will prompt the user for their password.
If that was confusing please let me know and I'll try to explain that a little more clearly.
Happy Holidays everyone!
CPUSERNAME
Hello
I'm trying to use GCF to sign me to one system using my luminis credentials and then redirect to another system that requires it's own credentials.
I can use CPUSERNAME and USERNAME to distinguish between usernames but there seems to be only PASSWORD. I ideally need a CPPASSWORD and a PASSWORD.
has anyone tried anything like this with the GFC?
No secret store entry required
Our experience is that you don't need a secret store entry.
Using cptool to create the External System Account, you'd use the following command:
If you set a zero length password e.g.
... then you can configure the CPIP to use the Luminis credentials.
I usually get someone else to do the CPIP though, so I'm little help there.
Hope this helps as a starter.
David.
password?
What about the password?
The luminis username does, but does the password?
having issues getting system credentials to work
Hello,
I have read all the replies in this post and I am trying to get this to work for a SSO GCF connector.
I did all the configuration steps (even the configman settings that Christine posted) but mine only works when I do the
cptool set user username ExternalAccount='cpipname||' command.
For someone that I haven't done that command I get the following message,
External system error
CPIP Notification: Faile to set default CPIP ligin info with params '{}' for per 'John Doe' with external ID 'null'
Has anyone else seen this? Or does anyone have any ideas what I might have missed or be doing wrong?
Thanks
using cpusername
Hello
I had a working GCF cpip using pickup.response created using ExternalAccounts. I chnaged my luminis password and this caused havoc. I came accross this post about using CPUSERNAME and have tried the above but the username that is being sent accross the wire is some sort of hashed gobbldygook rather than the plain text version. and this is the same gobbldygook if I use USERNAME or CPUSERNAME.
here is
1 my .properties section with cpipconnector settings:
rm_bking.cpipconnector.getconfig.createonlogin = 1
rm_bking.cpipconnector.getconfig.authenticate = ${rm_bking.urlBase}/Authenticate
rm_bking.cpipconnector.getconfig.authenticateOIDlist = 1.3.6.1.4.1.4409.1.1.4.2
rm_bking.cpipconnector.getconfig.deauthenticate = ${rm_bking.urlBase}/Deauthenticate
rm_bking.cpipconnector.getconfig.deauthenticateOIDlist = 1.3.6.1.4.1.4409.1.1.6.1
rm_bking.cpipconnector.getconfig.lastactive = ${rm_bking.urlBase}/LastActive
rm_bking.cpipconnector.getconfig.lastactiveOIDlist = 1.3.6.1.4.1.4409.1.1.5.1
rm_bking.cpipconnector.getconfig.sessionPlaceHolder = sessionPlaceHolder
rm_bking.cpipconnector.getconfig.sendcpsession = false
rm_bking.cpipconnector.getconfig.sendtimeout = false
rm_bking.cpipconnector.getconfig.desturl_parmname = destURL
rm_bking.cpipconnector.getconfig.sendlogin = true
rm_bking.cpipconnector.getconfig.useSISCredentials = false
rm_bking.cpipconnector.getconfig.configsleeptime =
rm_bking.cpipconnector.getconfig.configattempts =
rm_bking.cpipconnector.getconfig.shortcircutlogin = true
rm_bking.pickup.destURLParameter = url
2 my configman properties
es.rm_bking.configURL=http://luminis.shef.ac.uk:8008/cpipconnector/rm_bking/GetConfigVersion2
es.rm_bking.sendcpuid=true
es.rm_bking.shortcircuitlogin=true
es.rm_bking.createonlogin=1
I was wondering if someone could help me in the right direction in getting the plain text version of my luminis username
cheers
nomit
hmmm
Have now got it working.
Not sure what happened.
before trying the _CPUSERNAME route I recreated my luminis account.
Testing first with just _USERNAME created a pdsExternalSystemID value relating to my ExternalAccount value.
Then on switching to _CPUSERNAME in my properties file it seems that my ExternalAccount value was being passed as the username field?!
I recreated my account again and used _CPUSERNAME first off. my correct username is being passed now but a pdsExternalSystemID/ExternalAccount for this external system was still subsequently created.
Am I mistaken in thinking that using _CPUSERNAME was a way to avoid unnecessary ExternalAccount creation?
nomit
figured it out
just to close this thread again
I guess if you are using _CPUSERNAME , createonlogin=1 with cpool sync password to avoid ExternalAccount creation, you avoid the creation of the pdsPssEntry.The pdsExternalSystemID is just a flag for the ExternalAccount and doesn't seem to be used in the GCF.
As I note I did get this on the fly ExternalAccount creation working with just using createonlogin=1 and _CPUSERNAME in the GFC files, amd es.CPIPNAME.configURL. Didn't need
es.CPIPNAME.createonlogin=1
es.CPIPNAME.sendcpuid=true
es.CPIPNAME.shortcircuitlogin=true
cheers
useSISCredentials
Hi,
FYI, I was able to get the system credentials just by setting the following property to "true" in the connector properties file:
[sysname].cpipconnector.getconfig.useSISCredentials = true
Our Luminis system currently authenticates against its internal LDAP.
I didn't have to use {_CPUSERNAME} or sync password or change any configman settings. Also, I noticed that there is no ExternalAccount entry for the concerned system when I did a cptool get user.
Shyam
usePDSCredentials
Just wanted to add that when we switched Luminis to authenticate against an external LDAP (EAS), I used the "usePDSCredentials" setting in the cpip properties file to get the system credentials. As with the "useSISCredentials" setting, there were no changes in the XML operations file or configman settings. Also, no external account entry was created for users of the concerned system.
HTH,
Shyam
More on system credentials in a CPIP connector
Hi All:
Has anyone finally distilled the essence of what is required for a passing Luminis credentials to a CPIP accessed system, when the Luminis system itself is using an EAS?
I have tried a few variations on the suggestions here, but they seem quite 'temperamental', and I have no reliable working solution.
Cheers
Tony
A different experience all together...
Hmmm,
I just switched 2 CPIPs that we had setup previously to use usePDSCredentials. They were using a *copy* of the Luminis credentials stored in LDAP, which was a problem if a user changed their Luminis password (the copy would not be changed and a Luminis admin would have to clear the user's LDAP entry for the external system for the pickup/response CPIP). ...these were setup before started working on Luminis and I'm not sure if it was before the usePDSCredentials parameter was made available.
Anyway, I did different things for our 2 CPIPs...
(1) on the first CPIP all I had to do 2 configman commands:
Before I changed es.CPIPNAME.autosync from true, I would still be prompted for a username/password AND it was stored in the LDAP. After I changed this, no more prompt and no more LDAP entry.
BTW, this CPIP uses the pickup/response method, so the .xml file just has sections for AUTHENTICATE, DEAUTHENTICATE and CHECKSTATE with the RESULT set to true (no GET, POST or SEARCH commands). In the .properties file there is an html string that gets passed to the external system with _USERNAME ... I did *not* have to change it to _CPUSERNAME.
(2) on the second CPIP I converted, I did the same 2 configman commands, BUT I also had to change _USERNAME to _CPUSERNAME in the .xml file. This CPIP uses the pickup.html method.
For neither of the CPIPs did I have to do any cptool commands (the external accounts are all created separate from luminis... that is, we set createonlogin=false).
Not sure if this helps anyone???
Ginny Lee...Colorado School of Mines
Wildcard SSL certificates
Is anyone using a Wildcard certificate on their BB server? We are having a hell of a time getting our CPIP to work when we turn on the SSL in BB. Any feedback would be appreciated.
CACerts
See comment here, I think this will fix your problem. Even though this was ancient, maybe someone else will run across this.
http://www.lumdev.net/node/800#comment-1890
Making the GCF More Generic
Just a followup on this thread-we ran into the problem of not wanting to create separate credential sets for different systems a couple of years back. The above posts should definitely help you use the system credentials. But we found that many of the external systems we were targetting had different username/password field names and/or hidden form values. To abstract out these differences we created an 'even more generic connector'. I did a presentation on it for the developer's lounge last year-more details on this can be found at http://www.lumdev.net/?q=node/606. Hopefully this will help somebody.