|
See my comments below between <PB> and </PB> tags. Patrick Botz Senior Software Engineer eServer Security Architect (507) 253-0917, T/L 553-0917 email: botz@us.ibm.com "Westdorp, Tom" <Tom.Westdorp@StationC To: midrange-l@midrange.com asinos.com> cc: Sent by: Subject: Anne: Could you please relay a few EIM questions to Pat Botz or midrange-l-admin@midra his group? nge.com 05/16/2002 03:41 PM Please respond to midrange-l This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. -- [ Picked text/plain from multipart/alternative ] 1. EIM works with Win2K logins, will it work with WinXP logins and user switching capability and if so when? <PB> The EIM infrastructure is entirely user registry agnostic. It does not do any authentication. You can map from/to any user registry that you have defined to EIM. The iSeries single sign-on solution, is based on Kerberos. So, single sign-on does not depend on windows sign-ons. If you can load a Kerberos package on your desktop (no matter what it is), single sign-on will work. I believe, but do not know for sure that authentication in WinXP is essentially the same as Win2k. If so, then it is using Kerberos as the authentication mechanism whenever you sign-on to a Domain. If it isn't the same, then you would have to install a Kerberos package on XP also.</PB> 2. Given one login on the WinClient (assuming not 95, not 98, not ME but 2K or higher?) client, is there then an opportunity to select from multiple logins on an iSeries? (e.g. I log in to my PC, but when I got to one iSeries I then either login with a *USRPRF for Casinos or a *USRPRF for Hotels, to another iSeries for generic system stuff or Data Warehouse, to another iSeries for ???, etc.)<PB>From the EIM infrastructure point of view EIM can be used to model the fact that a user has multiple user IDs in a single user registry. The infrastructure also has the capability to allow admins to give particular identity associations "additional information" which is really just an arbitrary string. This will allow an application to be written such that the admin is instructed to add some string to the appropriate identity that should be used with an applicaiton. For example, if I have two IDs on myiseries1, botzadmin, and botzuser, and for some application, myapp1, I need EIM to select the admin ID, I could write the app to find the OS/400 user profile on myiseries1 that has additional information of "myapp1=use_this_one" or any other arbitrary string. So EIM supports this. HOWEVER, our current exploitation of EIM for single sign-on does not exploit this. I did not mention one concept in the presentation today due to time limitations. Not all EIM assocations are created equal. It turns out, that when you associate an ID with an EIM identifier, you have different types of associations to pick from, namely: source, target, both, admin. A source association means it can only be used as the source (i.e. the known or authenticated identity, Kerberos principals will nearly always be a source association) in a mapping. Standard mapping APIs will never find an identity that only has a source relationship. A target relationship means that this identity will be found by the standard mapping APIs; however, nothing would be returned if it happened to be used as the source in a mappin lookup operation. An admin relationship can't be used successfully as a source ID nor will it ever be returned as the target ID in mapping lookup operations. So, one way to manage this with today's exploitation is to create a target relationship with the ID you normally want the single sign-on operation to do (and perhaps set it's password to *NONE), and use an admin association for the other ID.</PB> 3. If a generic user logs into a PC, then uses a generic *USRPRF to log into an iSeries I assume that all goes okay (but really nowhere), but then we use individual logins to the applications (again on a one to several(?) relationship) will this need to be rewritten to a one to one relationship for EIM or will it need to exist outside of EIM? <PB> I'm not sure I understand this question. Perhaps the answer to the previous question might apply here. EIM can be used to model different types of relationships. A single EIM identifier may have many "source" identities and different target identities. I think of these as 1:1 relationships. For each source there is one relationship with each of the targets. There is also the case where 2 people share the same source identitiy (i.e. they share the id and password, not recommended, but it happens). There is a separate source relationship with this identity for each of the two EIM identifiers. I think of this as an n:1 relationship. Multiple people map to a likely different set of target identities. Mapping lookups will not work in this situation. EIM will return an "ambiguous result" if this source ID is used for mapping purposes. It knows there are two people this ID may represent and it can't tell the difference. Finally there is another model where two or more people share a target ID. This is what I think of as 1:n. Each individual has a uinque source identity, and they happen to map to a common target identity on more than one system. EIM mapping works fine in this case. If you are running the EIM domain controller on an iSeries LDAP server, you can get audit entries for each mapping lookup too. </PB> 4. Will WDT (specifically Code/400) be a player in EIM? <PB>No specific plans at this point. However I have lots of ideas for where EIM can be exploited and were pursuing a lot of them. If you have a specific requirement or scenario, I'd like to hear it.</PB> 5. Do they foresee any thin client (e.g. Citrix) implications? <PB>Not sure what you mean by implications. But, since mapping is really a server operation, I don't see any.</PB> Seemed like off-line questions to me so I saved the ConfCall folks the boredom. Thanks! _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.