Talking Identity (Comments)https://blogs.oracle.com/talkingidentity/feed/comments/atom2012-12-17T23:24:45+00:00Apache Rollerhttps://blogs.oracle.com/talkingidentity/entry/my_next_attempt_at_controversy#comment-1240448024000Re: My Next Attempt at Controversy: Roles and the (ir)relevance of NISTAlejandro Lapeyre2009-04-23T00:53:44+00:002009-04-23T00:53:44+00:00Another point of view is: The role is "Doctor of patient M". Since the many part is "patient M" it is the the patients who are assigned to the role. The role "Doctor of patient M" should be created as a child of the "Doctor X" user object. The role should be created automatically by the implementation whenever a user is assigned to the "Doctor" role. In this case we would have object specific roles, and not relationship roles, wich (I think) is also not considered in the standard. https://blogs.oracle.com/talkingidentity/entry/on_anonymity_pseudonymity_and#comment-1239773948000Re: On Anonymity, Pseudonymity and PersonasRobin Wilton2009-04-15T05:39:08+00:002009-04-15T05:39:08+00:00I tend to use a slightly different definition for "persona" from the ID Common one; I define it as "that subset of personal information which an individual chooses to disclose in a given context".
I think it's important to try and arrive at a definition which is as consistent as possible between 'real' and 'virtual' life. The idea of "choice" is important too; for me, personas are a way in which people seek to manage the impression they create when interacting - and 'management' implies some degree of control. Thus - I may choose to appear to my employers as a serious, diligent technocrat, and to my children as a kind, loving parent.
I think the distinction between a pseudonym and a persona is equivalent to the distinction between an identifier and a set of persona attributes. One (the pseudonym/identifier) is usually the "index" which allows you to find the other.
I discuss treatment of these 'indices' further in this paper from the Liberty Alliance Privacy Summit in Brussels (2007): www.➡.ws/踹⁝
https://blogs.oracle.com/talkingidentity/entry/more_things_about_federated_pr#comment-1239712087000Re: More Things about Federated ProvisioningFrank Villavicencio2009-04-14T12:28:07+00:002009-04-14T12:28:07+00:00Nishant:
A comment on the federated provisioning discussion that might be relevant... beyond the technical approach is also de SLA, and come to think about it, the liability implications. As you rightfully stated, for the most part federation hinges, in a practical way in local accounts at the RP being created and linked to the federated identity, which, if left dormant might create a potential thread. In my view this has a few implications, such as 1) the obvious one that you pointed out: dormant accounts can be exploited albeit through backdoor channels -- that's a strong reason to deal with them; 2) they used up digital space in systems and also in themselves, they represent a potential asset that could be exploited/abused, thus opening up potential privacy issues, simply on the data that the record itself is made up; 3) As someone pointed out, in SaaS environments, organizations are often charged based on the number of users from their end that are registered for the application, so there is a cost implication (not to say that simply keeping data around wouldn't in itself represent a cost), but this may also have liability implications to either the RP or the IdP, in the event that any of the above situations occurred, who is responsible for the potential damage caused? Is there an SLA or a clause somewhere that specifies how this is to be dealt with when things do go wrong? I propose that these elements, which are part of a federated identity network be addressed up front as the federation itself is being established, such that parties know what their responsibilities and liabilities are in the exchanges.
It is appropriate to refer to Bob Blakley’s work on relationships at this point, which to me is the basis for how trustworthy federation will take place. If you come to think about it, an effective way to ensure that accounts are terminated in a relatively timely fashion is to see that one of the parties, RP or IdP see an incentive in keeping the relationship up-to-date, and provided that they have the practical means to do so, there is a much higher chance that they will.
Another relevant observation comes from the world of identity assurance – if identity assurance is a continuum, a watermark so to say, over time, and particularly in a federated network, it will tend to decay over time unless it is refreshed and updated. This is why in many federated networks (particularly those that have a heavy heritage from PKI), the elements of expiration and renewal are so critical. This is a mechanism by which parties have a worst case metric for containing the level of decay (smells funny, doesn’t it?) of federated identities.
https://blogs.oracle.com/talkingidentity/entry/understanding_oims_generic_tec#comment-1239342560000Re: Understanding OIM's Generic Technology ConnectorDinkar Singh2009-04-10T05:49:20+00:002009-04-10T05:49:20+00:00I have some very specific questions about SPML/Generic technology connector option:
i. How to generate random password through SPML? Based on policy configuration within OIM.
ii. Can Secret Question/Answers be retrieved via SPML?
https://blogs.oracle.com/talkingidentity/entry/talking_identity_services_at_o#comment-1238456750000Re: Talking Identity Services at OpenWorldbiometric012009-03-30T23:45:50+00:002009-03-30T23:45:50+00:00Much has been discussed about Identity Theft, user ID's and Passwords stolen or hacked, credit cards being used without the owners knowledge and so on. Now there is a safe way of protecting your passwords and identity online from being copied, stolen and hacked by keyboard trojans, using your biometric fingerprint and face recognition, and even voice, to log on to web sites. By simply scanning your finger or face or voice you can log on to a web site, log on to your computer, and even encrypt files and folders. No more worrying about who might hack into your online accounts or even your email. No more remembering passwords or using the same passwords on many sites. This is an exciting new innovation from myBiodentity and they have about fourteen products that are enabled with biometrics including email encryption, password manager, virtual disk, and many more. You can read more at http://www.mybiodentity.com
https://blogs.oracle.com/talkingidentity/entry/international_data_privacy_day#comment-1238450727000Re: International Data Privacy Day: Real Problems, Real Solutionsbiometric012009-03-30T22:05:27+00:002009-03-30T22:05:27+00:00About Identity Theft and stolen passwords, recently I came across a site that uses Biometrics of finger, face and voice verification so the user just scans to log on. You can read more at http://www.mybiodentity.comhttps://blogs.oracle.com/talkingidentity/entry/more_things_about_federated_pr#comment-1236941770000Re: More Things about Federated ProvisioningDeborah Volk2009-03-13T10:56:10+00:002009-03-13T10:56:10+00:00Hi Nishant,
I was wondering about the business side of this equation, namely how many companies provision to SaaS apps today. Granted, not all SaaS apps are created equal and some don't even have a interface for provisioning but... I created a poll on LinkedIn at http://polls.linkedin.com/p/26723/ojkhm to capture results.
We've got a blog now but it doesn't have RSS just yet. Stop by and say hello!https://blogs.oracle.com/talkingidentity/entry/the_thing_about_federated_prov#comment-1234599628000Re: The Thing about Federated ProvisioningPat Patterson2009-02-14T08:20:28+00:002009-02-14T08:20:28+00:00Hi Nishant - <a href="http://blogs.sun.com/superpat/entry/federated_provisioning_liberty_to_the" rel="nofollow">here's one approach to scenario #2</a>.https://blogs.oracle.com/talkingidentity/entry/the_thing_about_federated_prov#comment-1233744541000Re: The Thing about Federated ProvisioningMat Hamlin2009-02-04T10:49:01+00:002009-02-04T10:49:01+00:00Nishant,
I know of multiple instances similar to what you have described in scenario #1, and at least one where SPML is used to seed the identity information to the federated partner. (I'm sure there are more)
I agree with some of the comments that the JIT scenario can be accomplished (and is on the Internet) with OpenID, but in most cases where I personally have used OpenID, the SP, directs me through a create process and gathers more information about me prior to final "provisioning."
For the enterprise space, it is likely that the data and process for creating accounts at Omega will reside within the walls of Acme, and possibly additional processes (like approvals) reside within Omega.
For these situations, I see two options:
1. As you presented, creating a "... standards-based interaction between the federation server and the provisioning server", thereby allowing Omega to initiate their provisioning process upon federation request. (assuming completed or non-existent provisioning processes at Acme)
2. Recognition of attempted access to Omega by Acme services followed by provisioning to Omega via the Acme provisioning server.
This could be all programmatic, or manual where the user is redirected to the Acme provisioning server interface to complete the Acme to Omega provisioning process. ...and it could all be synchronous with final redirects to Omega, or asynchronous with a notification to the user when access is available.https://blogs.oracle.com/talkingidentity/entry/the_thing_about_federated_prov#comment-1233740168000Re: The Thing about Federated ProvisioningNishant Kaushik2009-02-04T09:36:08+00:002009-02-04T09:36:08+00:00Karl,
Excellent dissection of scenario 2. Really expands on what I meant when I stated "the interaction between the federation server and the provisioning server has to be ... well-defined". It is because of all the reasons you have stated that I say scenario 2 is not like regular provisioning, in that it requires we enhance the SAML/SPML standards to accommodate the special needs you have defined, and also enhance the interaction between the federation servers and the provisioning engines.https://blogs.oracle.com/talkingidentity/entry/the_thing_about_federated_prov#comment-1233739853000Re: The Thing about Federated ProvisioningNishant Kaushik2009-02-04T09:30:53+00:002009-02-04T09:30:53+00:00Johannes,
You are right in that scenario 2 is sort-of like the OpenID/CardSpace interactions. But my context is enterprise federations, where there are far more complicated datasets and business policies (like approvals) involved. The OpenID interaction is much simpler due to the nature of internet transactions.https://blogs.oracle.com/talkingidentity/entry/the_thing_about_federated_prov#comment-1233736284000Re: The Thing about Federated ProvisioningKarl Miller2009-02-04T08:31:24+00:002009-02-04T08:31:24+00:00SAML-based federated SSO exists as an authentication token, not authorization, and not as a global record transmission and relay technology. The entire concept of federation is to pass enough information to create the new session in the service provider's environment. That may mean a 1:1 mapping or an N:1 mapping. If the mapping does not exist, this is where people have decided "well, if it doesn't exist, create it!" And this has some risks associated with it that should be carefully considered.
If we want to engage in "Federated Provisioning", it becomes necessary to modify the basic exchanges of the SAML messages to trap a "user not found / failed user mapping" event to initiate some provisioning event. In environments that want to look at Federated Provisioning, I frequently hear "just pull the information you need to create the user from the SAML assertion and create them." Here's where we start to see the bad idea. The SAML assertion should contain the MINIMUM information for moving the session from the IdP to the SP.
If we instead send a full payload of data needed by the SP, we're likely transmitting FAR more information that would be advisable (recall that the first steps taken by Liberty and embraced in SAML 2.0 are opaque identifiers to further remove personal information from the exchange in order to provide better security because of the risks of misuse and replay.) Also, this means that the SP would have to expose sufficient information about what their business requires to the IdP, or build the business logic and dependencies into the federation processing. Neither is a very good idea.
Next, if we have opted to transmit the entire record payload from the IdP to the SP (and violated some very good security practices), modified the SAML exchange to add our provisioning process as an in-sequence requirement to federation, and created a new record with all the required data, we must now re-use the original assertion to create the user federation record. At worst, this means we're reusing what should be a short-lifetime SAML assertion to create a session. At best, we've degraded the performance of the federation exchange and mapping to add all the overhead for the provisioning process (including performance of all back-end servers in the provisioning process), and removed the value of any caching the provisioning server was using against the user repository (since we first looked and the record did not exist, so we created one, looked again and found the new record, we've got either a small or no cache.)
If we instead extend the SAML exchange for federation as a standard to allow a hook for provisioning as an option, with methods to notify the providers, then it may make sense to create 'Federated Provisioning'. Without that type of alteration, injecting the provisioning process should be an option that is implemented cautiously on a case-by-case basis at deployments.
If the organizations involved in a federated exchange have no prior negotiation for the user mappings, they probably should reconsider their federation agreement and examine their security practice for exchanging security for adminsitrative ease.
https://blogs.oracle.com/talkingidentity/entry/the_thing_about_federated_prov#comment-1233667752000Re: The Thing about Federated ProvisioningChris Winteregg2009-02-03T13:29:12+00:002009-02-03T13:29:12+00:00Nishant, as SAML and SPML do not integrate today in the standards and the integration could be "complex" and not standard, why can't we simplify the scenario 2. The idean would be that the federation service creates automatically the non-existing user at the SP side using standards like LDAP or JDBC depending what is the user repository? After all, the SAML profile would have all the necessary attributes info about the user ID. Would that break the SAML or Liberty standard ? https://blogs.oracle.com/talkingidentity/entry/the_thing_about_federated_prov#comment-1233663820000Re: The Thing about Federated ProvisioningJohannes Ernst2009-02-03T12:23:40+00:002009-02-03T12:23:40+00:00Seems to me that your "Scenario 2: Just-In-Time Provisioning" is the default OpenID scenario?
Given that this works on the open internet today, is it really so complicated? Does it have to be?https://blogs.oracle.com/talkingidentity/entry/on_anonymity_pseudonymity_and#comment-1232033748000Re: On Anonymity, Pseudonymity and PersonasShanahan2009-01-15T15:35:48+00:002009-01-15T15:35:48+00:00Foolstr.com explores this concept of persona; complete anonymity. It's using OpenID but not requesting any personal information. All that's required is an otherwise meaningless PPID. Jyte takes the opposite approach and captures email, first/last name. The question is will folks will be more inclined to share opinions if they are anonymous? Or will the interaction be less meaningful due to the lack of personal identification?
http://foolstr.comhttps://blogs.oracle.com/talkingidentity/entry/on_anonymity_pseudonymity_and#comment-1231865990000Re: On Anonymity, Pseudonymity and PersonasRob Cottingham2009-01-13T16:59:50+00:002009-01-13T16:59:50+00:00Thanks for sharing the cartoon with your readers - I'm glad you liked it!https://blogs.oracle.com/talkingidentity/entry/is_ad_really_the_dominant_iden#comment-1231256459000Re: Is AD really the dominant Identity Store out there?Trent2009-01-06T15:40:59+00:002009-01-06T15:40:59+00:00If allow guest access or partner/contractor access onto your network, you don't want to add these people to the corp. AD do you? A 2nd identity store could be useful and alleviate management and resource headaches. I'm not sure you'd need a full blow 2nd AD though. https://blogs.oracle.com/talkingidentity/entry/is_ad_really_the_dominant_iden#comment-1227605868000Re: Is AD really the dominant Identity Store out there?guest2008-11-25T09:37:48+00:002008-11-25T09:37:48+00:00 Martin said:
AD is a perfectly acceptable directory.
What deficiency or defect exists in AD that *requires* a company to add a second directory?
Answer: Platformhttps://blogs.oracle.com/talkingidentity/entry/delving_deeper_into_relationsh#comment-1223407058000Re: Delving deeper into Relationship-based RBACSharad Goel2008-10-07T19:17:38+00:002008-10-07T19:17:38+00:00Firstly let me say that this pandora's box should have been opened a long time back. Relationship based RBAC is something that is seen more and more common in enterprise applications. Every vendor has tried to implement this in their own way and a couple of interesting research articles have been written on this, but a standard solution has not been implemented.
The crux of the problem is simple - every user has a role to play in the system, and based on this role the user is allowed to perform certain actions (for e.g. viewing a record, modifying a record, or some other custom action). These action should only available to the user within a certain context. One of the facets of this context is the relationship the user has with the resource the user is trying to perform the action on. So for example, lets assume there is a role called Doctor. Using the regular RBAC how can you specify the following control access rule: "Doctors are allowed to view patient records for only those patients that have been treated."? After a while you will realize RBAC will not let you do this easily because you will end up creating a Role called Doctor and a permission called "View patient record" and associate this permission to the Doctor role.
What we really need to be able to do is to create a relationship between the Doctor and the Patient record and based on that relationship give the appropriate permissions.
I do hope that this is only the beginning of a discussion that can spawn off a standard solution for implementing relationship based RBAC.https://blogs.oracle.com/talkingidentity/entry/new_ideas_in_password_manageme#comment-1222823071000Re: New Ideas in Password Managementjaymz2008-10-01T01:04:31+00:002008-10-01T01:04:31+00:00what if you had to type another minimum equal length expression in the same field when you enter your password.
SAM would keep a history of the insignificant phrases you had used and refuse to let you use the same one within however many retries (this number could be modulated too to get around scripts)
anyone grabbing the hash for your password would then, after trying to de-hash it, have to key in a phrase INCLUDING the bits that are your password but which is not a phrase you have used within the appropriate number of retries.
maybe this phrase could be from a list of legal phrases or maybe this would just be defeating the point, but i reckon this would be pretty hard to crack if implemented (with any flaws ironed out!)
jaymzhttps://blogs.oracle.com/talkingidentity/entry/whoa_talk_about_trying_to_spre#comment-1221493823000Re: Whoa! Talk about trying to spread FUDSimon2008-09-15T15:50:23+00:002008-09-15T15:50:23+00:00Nishant, Paul,
Nothing like a bit of vendor-and-vendor competition going on :)
Having evaluated, and also implemented, Waveset & Thor both under their previous and current ownership, I can see both sides of the "discussion" that is ongoing.
In my opinion, both products are the best in the industry. However they are both at the opposite ends of the spectrum in terms of information architecture - one goes for the "pointer/meta" approach, whereas the other goes for the centralised-copy-and-reconcile approach.
Both are good approaches, but to be honest the difference between them isn't much, and not something that can't be got around through configuration. But at the end of the day, its what meets the customer's needs and their own enterprise architecture is what makes the choice.
Being "big bad" Oracle doesn't help in all cases, indeed in a number of cases it can be more than a hinderence! Both vendors have the ability to "bundle" or "give away" their IdM suite with software or hardware, so I think both sides are "pots calling the kettle black" in this case.
Both products are a lot weaker than what customers expect in full out-of-the-box ERP integration (this is also true for the whole industry). This is somethiing they need to improve on. We had the same issue with Roles a few years ago- now all the vendors have improved their in-built support, and also acquired/extended with pure-play Role Management product sets. So I assume that the same will occur for integration *within* ERP systems and not just *to* ERP systems - competition is healthy regardless!
Kind Regards
Simon
https://blogs.oracle.com/talkingidentity/entry/understanding_oims_generic_tec#comment-1220494274000Re: Understanding OIM's Generic Technology ConnectorKishoreM2008-09-04T02:11:14+00:002008-09-04T02:11:14+00:00Hi,
Please provide a demo program for User Provisioning.
thanks and regards
KishoreMhttps://blogs.oracle.com/talkingidentity/entry/announcing_oracle_identity_man#comment-1220475503000Re: Announcing Oracle Identity Manager 9.1KishoreM2008-09-03T20:58:23+00:002008-09-03T20:58:23+00:00Hi,
I need the details how to provision data from OIM to target system using webservices. what all are the things that are required to be done in OIM and target system for this purpose? if possible can i get some sample demo programs ?https://blogs.oracle.com/talkingidentity/entry/does_usercentric_also_mean_use#comment-1220419230000Re: Does 'User-Centric' also mean 'User-Burdened'?TCarroll2008-09-03T05:20:30+00:002008-09-03T05:20:30+00:00I suppose the extent of the burden on the user really depends on what PII they need to give to each system in order to accomplish their goals. In an on-line shopping scenario, you need to provide real payment credentials, and a real shipping address (or at least some kind of proxys that will get the job done), so there is limited ability for a user to easily keep that kind of transaction completely non-correlatable. On the other hand, many on-line transactions require only proving a) you're not a bot, and b) you are the same person you were last time. Systems based on Information Card technology, such as Microsoft's <a href="http://netfx3.com/content/WindowsCardspaceHome.aspx" rel="nofollow nofollow" rel="nofollow">CardSpace</a>, Parity Communication's <a href="http://www.azigo.com" rel="nofollow nofollow" rel="nofollow">Azigo</a> and Novell's <a href="http://www.bandit-project.org/index.php/Digital_Me" rel="nofollow nofollow" rel="nofollow">Digital Me</a> all include the capablity to automatically generate strong site-specific login credentials from a single Information Card, as well as the ablity to easily create multiple Information Cards to support different personas. Add in a disposable email service, and it becomes very easy for a user to maintain this kind of lightweight on-line account in a completely non-correlatable way.https://blogs.oracle.com/talkingidentity/entry/its_that_didw_time_of_the_year#comment-1220024677000Re: It's that DIDW time of the yearMatt Flynn2008-08-29T15:44:37+00:002008-08-29T15:44:37+00:00Nishant, hope you can join us.
http://360tek.blogspot.com/2008/08/digital-id-world-bloggers-unite.html
Looks like it's going to be Monday evening at 6pm in the exhibit area.https://blogs.oracle.com/talkingidentity/entry/were_number_1_were_number_1#comment-1219735450000Re: We're Number 1! We're Number 1!Nishant Kaushik2008-08-26T07:24:10+00:002008-08-26T07:24:10+00:00Didn't skip it (I left the complete quote in), just can't speak to it as authoritatively as I can about the product improvements.https://blogs.oracle.com/talkingidentity/entry/a_little_more_on_openid_adopti#comment-1219690694000Re: A little more on OpenID adoptionScott Kveton2008-08-25T18:58:14+00:002008-08-25T18:58:14+00:00There is something like the identity assurance framework being developed as an OpenID extension:
http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.html
This has been integrated into many of the libraries already shipping in the wild:
http://janrain.com/blog/2007/10/24/pape-support-in-janrain-openid-20-libraries/
FYI.https://blogs.oracle.com/talkingidentity/entry/were_number_1_were_number_1#comment-1219681428000Re: We're Number 1! We're Number 1!James2008-08-25T16:23:48+00:002008-08-25T16:23:48+00:00I love the way you skipped over the sales aspect :-)https://blogs.oracle.com/talkingidentity/entry/johannes_talks_about_the_openi#comment-1219405596000Re: Johannes talks about the OpenID RP &quot;Problem&quot;Nishant Kaushik2008-08-22T11:46:36+00:002008-08-22T11:46:36+00:00Mark,
Interesting questions. I will think about it a bit and post my response in an upcoming post. But here's a preview: I think your second question kind of points out the answer to question number 1.
Nishanthttps://blogs.oracle.com/talkingidentity/entry/johannes_talks_about_the_openi#comment-1219380810000Re: Johannes talks about the OpenID RP &quot;Problem&quot;Mark Workel2008-08-22T04:53:30+00:002008-08-22T04:53:30+00:00Hi Nishant,
Good article, I have two questions:
1. What are the strategic advantages of becoming an IdP?
2. As a consumer or RP, how do I know if an IdP is reliable?
I hope you can answer these questions, or maybe talk about them in your next posting.