Re: [openxdas-devel] Peer associations?

[David C. <dco...@no...>]

Hi Wayne,

I've included what I think below:

>>> On Fri, Apr 27, 2007 at  1:06 PM, Wayne Hsu wrote:=20
> An IDM User application runs in a Linux server but the user identity =
is=20
> stored and authenticated through eDirectory in another Linux server. =
One=20
> event is generated when the administrator whose DN in eDirectory is=20
> *cn=3Dadmin,ou=3Didmsample,o=3Dnovell* changed the password of a user =
*whsu* whose=20
> DN is *cn=3Dwhsu,ou=3Didmsample,o=3Dnovell*. Let*s say user *whsu* is =
the target.=20
> What will be the data being stored in those target fields? I filled up =
the=20
> XDAS fields with the following data based on my understanding of the =
field=20
> definition. As you can see, I am missing the most important data: the =
name of=20
> the user whose password has been changed. Also, can we say that user =
whsu is=20
> located in the <host name>/IdmUserApp but is authenticated by the =
<host=20
> name>/eDirectory?
>=20
> Event Number: XDAS_AE_MODIFY_AUTH_TOKEN
> Initiator Authentication Authority: <host name>/eDirectory
> Initiator Domain-Specific Name: cn=3Dadmin,ou=3Didmsample,o=3Dnovell
> Initiator Domain-Specific ID: cn=3Dadmin,ou=3Didmsample,o=3Dnovell
> Target Location Name: <host name>/eDirectory
> Target location address: url to the eDirectory
> Target Service Type: ldap
> Target Authentication Authority: host name>/eDirectory
> Target Princial Name: don*t know  (User name under which eDirectory =
is=20
> running)

No, I think the target in this case is the user, not eDirectory.  So I =
would put the username in this field.  I imagine there will actually be a =
couple events generated here, one by the User App and one when eDir =
receives the password change (the attempt and the result, so to speak).

> Target Principal ID: don*t know (User ID under which app server is =
running)


> I also have the following questions:
>=20
> 1.	What*s the value of Target Princial Name/ID? In most cases, we =
don*t know=20
> or care about that information.=20

That's why I think in this case the target is the username.

> 2.	Like wise, what*s the value of the Originator/Initiator/TargetPrinc=
ipal=20
> ID? Can*t the Original/Initiator/TargetPrincipal Name be enough? In =
most=20
> cases, we don*t know or care about the ID. I know we can hard-code root =
ID to=20
> 0, but what's the value of it? For user other than root, it is difficult =
to=20
> obtain the ID without the administor privilege in the authentication =
service.=20

I somewhat agree, but in some cases events I have seen include both pieces =
of information.  Also consider the case where the target is a network port =
- in this case the name/ID of the port can be trivially retrieved from the =
services file.




HTH