For a project I need to log in a user using an agent or a servlet on a Domino server.

Does anyone know of a way to do this without knowing the users' password?

It must be done in Single Sign On solutions so somehow it must be possible.

Any thoughts anoyone?

Hi Tomas, 

I have only read some about this but as far as I know the username and password must always be known one way or the other, at least indirect. 

For Single Sign-On solutions on web-based systems you get authorized when accessing for example a Domino server. A LTPA-token (cookie) is sent back to the browser, after providing username and password, which let's you access other systems using the browser thank's to background communication and handshaking between different directories (for example between Domino and LDAP or AD).

This way the password is not needed when seemlessly logging on to other systems but the authorization has already been taking care of and an agreement written in the LTPA-token.

Here are two good articles about this:
- Single Sign-On in a Multi-directory World: Never say login again: Part1
- Single Sign-On in a Multi-directory World: Never say login again: Part2

And a guide:
- Guide to configuring Single Sign-On (SSO)

I don't know if this is what you were looking for, but at least a thought!

// Niklas

Yes, there is a way. But you'll have to go the c route (or Java->C using JNI) by using the following function:

STATUS LNPUBLIC SECTokenGenerate(
 char *ServerName,
 char *OrgName,
 char *ConfigName,
 char *UserName,
 TIMEDATE *Creation,
 TIMEDATE *Expiration,
 MEMHANDLE *retmhToken,
 DWORD  dwReserved,
 void *vpReserved);

"Use this function to generate an authentication token for interoperability with Domino protocols that support Single Sign-On (IE: HTTP and DIIOP), as well as IBM WebSphere Advanced Server. The return value retmhToken is a MEMHANDLE that references an SSO_TOKEN structure when locked with OSMemoryLock. See SSO_TOKEN for more information.

Note: this function will be remoted in a future release."

Kind regards

Daniel

That is some powerful stuff there Daniel and welcome here!

It must be 8 years since we worked together last time?

I will read up on the SECTokenGenerate and the SSO_TOKEN.

This is a good place to start:
http://www-128.ibm.com/developerworks/lotus/documentation/capi/

Thanks Tomas,

Nice to be here and to see yet another great Domino forum. I normally check Thomas Adrians site (notessidan.se) but will be around here as well. Great awareness functionality btw :)

Additional note for the sectokengen. stuff. If you don't want to go the api-route, there is a way to generate the sso-token yourself (if you have access to the server). An sso-token consists of two parts, a "public" one with a canonical username, ldap server name and port and session timeout value, and finally a "secret" part with the "hidden secret" found in the LTPA document. the "secret" part exists in the LTPA_DominoSecret item

( have some ready made code that will "decrypt" a sso-cookie btw).

To create and validate an sso-token do like this:

To generate a Domino style Single Sign-On token

1. Read the BASE-64 encoded secret data from the LTPA_DominoSecret field of the Web SSO Configuration.
2. Read the expiration interval from the LTPA_TokenExpiration field of the Web SSO Configuration.
2. Begin with the 4 bytes of versioning header information.
- Version 0 is [0x00][0x01][0x02][0x03]
3. Append the creation time.
- Creation time is represented as an offset in seconds from 1/1/1970 12:00 GMT.
- It is encoded as an 8 character hexadecimal string. Use printf() with the %08x modifier.
4. Append the expiration time.
- Expiration time is also represented as an offset in seconds from 1/1/1970 12:00 GMT.
- It is encoded as a 8 character hexadecimal string. Use printf() with the %08x modifier.
5. Append the Username.
- There is no restriction on the format of the Username, but the LMBCS fully labeled canonical name is recommended, with a maximum length of MAXUSERNAME.
6. Generate a SHA-1 hash (20 bytes) over the data that has been concatenated plus the 20 byte shared secret.
7. Append the SHA-1 hash after the Username.
8. BASE-64 encode the final token.

To validate a Domino style Single Sign-On token

1. Read the BASE-64 encoded secret data from the LTPA_DominoSecret field of the Web SSO Configuration.
2. BASE-64 decode the token to its raw bytes.
3. Calculate the length of the variable length data for the username.
- variable_length = total_length - immutable_length (40 bytes)
- The variable_length part of the token must be > 0. If not, the token is invalid.
4. Verify the integrity of the token by checking the hash.
- Generate a SHA-1 hash over the token (excluding the hash contained in the token) and the 20 byte shared secret.
- Compare this hash to the one contained in the token. If they match, then the token is valid.
5. Parse the first 4 bytes of header information.
- Version 0 is [0x00][0x01][0x02][0x03]
6. Parse the creation time.
7. Parse and enforce the token expiration time.
8. Parse the Username.

Thanks Tomas,

Nice to be here and to see yet another great Domino forum. I normally check Thomas Adrians site (notessidan.se) but will be around here as well. Great awareness functionality btw :)

Additional note for the sectokengen. stuff. If you don't want to go the api-route, there is a way to generate the sso-token yourself (if you have access to the server). An sso-token consists of two parts, a "public" one with a canonical username, ldap server name and port and session timeout value, and finally a "secret" part with the "hidden secret" found in the LTPA document. the "secret" part exists in the LTPA_DominoSecret item

( have some ready made code that will "decrypt" a sso-cookie btw).

To create and validate an sso-token do like this:

To generate a Domino style Single Sign-On token

1. Read the BASE-64 encoded secret data from the LTPA_DominoSecret field of the Web SSO Configuration.
2. Read the expiration interval from the LTPA_TokenExpiration field of the Web SSO Configuration.
2. Begin with the 4 bytes of versioning header information.
- Version 0 is [0x00][0x01][0x02][0x03]
3. Append the creation time.
- Creation time is represented as an offset in seconds from 1/1/1970 12:00 GMT.
- It is encoded as an 8 character hexadecimal string. Use printf() with the %08x modifier.
4. Append the expiration time.
- Expiration time is also represented as an offset in seconds from 1/1/1970 12:00 GMT.
- It is encoded as a 8 character hexadecimal string. Use printf() with the %08x modifier.
5. Append the Username.
- There is no restriction on the format of the Username, but the LMBCS fully labeled canonical name is recommended, with a maximum length of MAXUSERNAME.
6. Generate a SHA-1 hash (20 bytes) over the data that has been concatenated plus the 20 byte shared secret.
7. Append the SHA-1 hash after the Username.
8. BASE-64 encode the final token.

To validate a Domino style Single Sign-On token

1. Read the BASE-64 encoded secret data from the LTPA_DominoSecret field of the Web SSO Configuration.
2. BASE-64 decode the token to its raw bytes.
3. Calculate the length of the variable length data for the username.
- variable_length = total_length - immutable_length (40 bytes)
- The variable_length part of the token must be > 0. If not, the token is invalid.
4. Verify the integrity of the token by checking the hash.
- Generate a SHA-1 hash over the token (excluding the hash contained in the token) and the 20 byte shared secret.
- Compare this hash to the one contained in the token. If they match, then the token is valid.
5. Parse the first 4 bytes of header information.
- Version 0 is [0x00][0x01][0x02][0x03]
6. Parse the creation time.
7. Parse and enforce the token expiration time.
8. Parse the Username.

Very powerfull stuff!

Here is an update in the matter.

JEDS har written good blog post about the creations of tokens and a java class that builds an ltpa token for you.

http://blogs.nil.com/jeds/2009/04/04/ltpa-token/