Re: [Freeipa-users] Extending IPA schema for Federation services.

2012-03-19 Thread Rob Crittenden

Steven Jones wrote:

Hi,


Is it possible to expand IPA's schema to do this?


Adding the schema is easy, doing something with it is where things get 
interesting. What do you want to do with these attributes/objectclasses?


rob

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Extending IPA schema for Federation services.

2012-03-19 Thread Steven Jones
Hi,

Im starting from scratch here so bear with me..ie I dont know a lot of 
thiswhich should be obvious

Extending Easy? oh because it doesnt strike me as easy..

:/

Initially I am about to build our production IPA servers.  These attributes are 
a requirement of the Federation system New Zealand wants to use and is probably 
the same for Australia. So I think the schema has to be done/extended for IPA 
to be viable in tertiary institutions in NZ, without it not many if anyone will 
use IPA they will stay with openldap.  So each person should have these I 
think.they may not be used initially but once extended initially then I 
dont have to extend the schema later.

What connects to these is an apache/tomcat front end. There are two 
aspects/functions to this, the IdP and the SdP.  The Idp allows remote tertiary 
organisations to query us and say our user is we legitthey then use their 
LDAP to provide resources via the SdP.  So the Idp provides an identity to 
remote ppl and the SdP provides access to a resource at our end. later I expect 
we will have to to the SdP bit got our high performance cluster and storage...

It maybe a year or more before we actually use this, but it strikes me as 
sensible that these are done on initial build.I will put ina  RH support 
case for this.   We will probably also pull the actual fields/contents out of 
AD.not sure yet.

regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ

0064 4 463 6272


From: Rob Crittenden [rcrit...@redhat.com]
Sent: Tuesday, 20 March 2012 2:55 a.m.
To: Steven Jones
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Extending IPA schema for Federation services.

Steven Jones wrote:
 Hi,


 Is it possible to expand IPA's schema to do this?

Adding the schema is easy, doing something with it is where things get
interesting. What do you want to do with these attributes/objectclasses?

rob

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Extending IPA schema for Federation services.

2012-03-19 Thread Dmitri Pal
On 03/19/2012 03:58 PM, Steven Jones wrote:
 Hi,

 Im starting from scratch here so bear with me..ie I dont know a lot of 
 thiswhich should be obvious

 Extending Easy? oh because it doesnt strike me as easy..

 :/

 Initially I am about to build our production IPA servers.  These attributes 
 are a requirement of the Federation system New Zealand wants to use and is 
 probably the same for Australia. So I think the schema has to be 
 done/extended for IPA to be viable in tertiary institutions in NZ, without it 
 not many if anyone will use IPA they will stay with openldap.  So each person 
 should have these I think.they may not be used initially but once 
 extended initially then I dont have to extend the schema later.

 What connects to these is an apache/tomcat front end. There are two 
 aspects/functions to this, the IdP and the SdP.  The Idp allows remote 
 tertiary organisations to query us and say our user is we legitthey then 
 use their LDAP to provide resources via the SdP.  So the Idp provides an 
 identity to remote ppl and the SdP provides access to a resource at our end. 
 later I expect we will have to to the SdP bit got our high performance 
 cluster and storage...

 It maybe a year or more before we actually use this, but it strikes me as 
 sensible that these are done on initial build.I will put ina  RH support 
 case for this.   We will probably also pull the actual fields/contents out of 
 AD.not sure yet.


The question is simple: how you plan to manage these attributes in IPA?
Do you expect them to be a part of the UI/CLI or they should be hidden
there and be managed via ldapmodify and other data sync tools?

This make the whole difference especially the UI part. Depending upon
these expectations the scope would be different.


 regards

 Steven Jones

 Technical Specialist - Linux RHCE

 Victoria University, Wellington, NZ

 0064 4 463 6272

 
 From: Rob Crittenden [rcrit...@redhat.com]
 Sent: Tuesday, 20 March 2012 2:55 a.m.
 To: Steven Jones
 Cc: freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] Extending IPA schema for Federation services.

 Steven Jones wrote:
 Hi,


 Is it possible to expand IPA's schema to do this?
 Adding the schema is easy, doing something with it is where things get
 interesting. What do you want to do with these attributes/objectclasses?

 rob

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Extending IPA schema for Federation services.

2012-03-19 Thread Steven Jones
Hi,

Is it sensible/better to extend the scheme before I start adding users? or 
doesnt it matter?  From my perspective extending a system in use carries risk 
and impact to users, so its seems safer to extend it before I have any users, 
even if its un-used for now/?

Apart from that I dont knowfor now I would live with the extended schema 
for the userpopulating the fields would be something I would look at when 
its decided what we will be doingno one yet knows or at least have not told 
me what they will be doing.

I suspect in the end we will draw the contents from AD with winsync?  

or populate/inject it directly via our Oracle identity system..so I'm not 
sure we will need the ui / guiI dont expect to add content via it, I 
suspect I might need to fault find to make sure the data is there but I assume 
ldap search tools will return this anyway?

However for other sites they may well not have an AD or user provisioning 
system...

regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ

0064 4 463 6272


From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on 
behalf of Dmitri Pal [d...@redhat.com]
Sent: Tuesday, 20 March 2012 9:19 a.m.
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Extending IPA schema for Federation services.

On 03/19/2012 03:58 PM, Steven Jones wrote:
 Hi,

 Im starting from scratch here so bear with me..ie I dont know a lot of 
 thiswhich should be obvious

 Extending Easy? oh because it doesnt strike me as easy..

 :/

 Initially I am about to build our production IPA servers.  These attributes 
 are a requirement of the Federation system New Zealand wants to use and is 
 probably the same for Australia. So I think the schema has to be 
 done/extended for IPA to be viable in tertiary institutions in NZ, without it 
 not many if anyone will use IPA they will stay with openldap.  So each person 
 should have these I think.they may not be used initially but once 
 extended initially then I dont have to extend the schema later.

 What connects to these is an apache/tomcat front end. There are two 
 aspects/functions to this, the IdP and the SdP.  The Idp allows remote 
 tertiary organisations to query us and say our user is we legitthey then 
 use their LDAP to provide resources via the SdP.  So the Idp provides an 
 identity to remote ppl and the SdP provides access to a resource at our end. 
 later I expect we will have to to the SdP bit got our high performance 
 cluster and storage...

 It maybe a year or more before we actually use this, but it strikes me as 
 sensible that these are done on initial build.I will put ina  RH support 
 case for this.   We will probably also pull the actual fields/contents out of 
 AD.not sure yet.


The question is simple: how you plan to manage these attributes in IPA?
Do you expect them to be a part of the UI/CLI or they should be hidden
there and be managed via ldapmodify and other data sync tools?

This make the whole difference especially the UI part. Depending upon
these expectations the scope would be different.


 regards

 Steven Jones

 Technical Specialist - Linux RHCE

 Victoria University, Wellington, NZ

 0064 4 463 6272

 
 From: Rob Crittenden [rcrit...@redhat.com]
 Sent: Tuesday, 20 March 2012 2:55 a.m.
 To: Steven Jones
 Cc: freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] Extending IPA schema for Federation services.

 Steven Jones wrote:
 Hi,


 Is it possible to expand IPA's schema to do this?
 Adding the schema is easy, doing something with it is where things get
 interesting. What do you want to do with these attributes/objectclasses?

 rob

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users


--
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Extending IPA schema for Federation services.

2012-03-19 Thread Rob Crittenden

Steven Jones wrote:

Hi,

Is it sensible/better to extend the scheme before I start adding users? or 
doesnt it matter?  From my perspective extending a system in use carries risk 
and impact to users, so its seems safer to extend it before I have any users, 
even if its un-used for now/?


If you do it later you may need to write a script to update all existing 
users with the missing objectclasses.



Apart from that I dont knowfor now I would live with the extended schema 
for the userpopulating the fields would be something I would look at when 
its decided what we will be doingno one yet knows or at least have not told 
me what they will be doing.


It matters depending on whether the attributes in those objectclasses 
are required or not.



I suspect in the end we will draw the contents from AD with winsync?


The list of attributes for winsync is currently hardcoded.



or populate/inject it directly via our Oracle identity system..so I'm not 
sure we will need the ui / guiI dont expect to add content via it, I 
suspect I might need to fault find to make sure the data is there but I assume 
ldap search tools will return this anyway?


Right, it is possible to use the IPA LDAP server as a data store, the 
framework need not know about these extra attributes.




However for other sites they may well not have an AD or user provisioning 
system...

regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ

0064 4 463 6272


From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on 
behalf of Dmitri Pal [d...@redhat.com]
Sent: Tuesday, 20 March 2012 9:19 a.m.
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Extending IPA schema for Federation services.

On 03/19/2012 03:58 PM, Steven Jones wrote:

Hi,

Im starting from scratch here so bear with me..ie I dont know a lot of 
thiswhich should be obvious

Extending Easy? oh because it doesnt strike me as easy..

:/

Initially I am about to build our production IPA servers.  These attributes are 
a requirement of the Federation system New Zealand wants to use and is probably 
the same for Australia. So I think the schema has to be done/extended for IPA 
to be viable in tertiary institutions in NZ, without it not many if anyone will 
use IPA they will stay with openldap.  So each person should have these I 
think.they may not be used initially but once extended initially then I 
dont have to extend the schema later.

What connects to these is an apache/tomcat front end. There are two 
aspects/functions to this, the IdP and the SdP.  The Idp allows remote tertiary 
organisations to query us and say our user is we legitthey then use their 
LDAP to provide resources via the SdP.  So the Idp provides an identity to 
remote ppl and the SdP provides access to a resource at our end. later I expect 
we will have to to the SdP bit got our high performance cluster and storage...

It maybe a year or more before we actually use this, but it strikes me as 
sensible that these are done on initial build.I will put ina  RH support 
case for this.   We will probably also pull the actual fields/contents out of 
AD.not sure yet.



The question is simple: how you plan to manage these attributes in IPA?
Do you expect them to be a part of the UI/CLI or they should be hidden
there and be managed via ldapmodify and other data sync tools?

This make the whole difference especially the UI part. Depending upon
these expectations the scope would be different.



regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ

0064 4 463 6272


From: Rob Crittenden [rcrit...@redhat.com]
Sent: Tuesday, 20 March 2012 2:55 a.m.
To: Steven Jones
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Extending IPA schema for Federation services.

Steven Jones wrote:

Hi,


Is it possible to expand IPA's schema to do this?

Adding the schema is easy, doing something with it is where things get
interesting. What do you want to do with these attributes/objectclasses?

rob

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



--
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Extending IPA schema for Federation services.

2012-03-19 Thread Dmitri Pal
On 03/19/2012 05:34 PM, Rob Crittenden wrote:
 Steven Jones wrote:
 Hi,

 Is it sensible/better to extend the scheme before I start adding
 users? or doesnt it matter?  From my perspective extending a system
 in use carries risk and impact to users, so its seems safer to extend
 it before I have any users, even if its un-used for now/?

 If you do it later you may need to write a script to update all
 existing users with the missing objectclasses.


So yes it is better to do now.

 Apart from that I dont knowfor now I would live with the extended
 schema for the userpopulating the fields would be something I
 would look at when its decided what we will be doingno one yet
 knows or at least have not told me what they will be doing.

 It matters depending on whether the attributes in those objectclasses
 are required or not.

 I suspect in the end we will draw the contents from AD with winsync?

 The list of attributes for winsync is currently hardcoded.

Probably some custom ldapmodify or CLI with setatttr/addattr based
solution. It can be done just not something generic so probably will be
left to you to script against the data source.



 or populate/inject it directly via our Oracle identity system..so
 I'm not sure we will need the ui / guiI dont expect to add
 content via it, I suspect I might need to fault find to make sure the
 data is there but I assume ldap search tools will return this anyway?

 Right, it is possible to use the IPA LDAP server as a data store, the
 framework need not know about these extra attributes.

Framework meaning the management interfaces i.e. UI/CLI. But CLI is
smart and can access LDAP attributes if they are available in the object
via --setattr/--addattr



 However for other sites they may well not have an AD or user
 provisioning system...

 regards

 Steven Jones

 Technical Specialist - Linux RHCE

 Victoria University, Wellington, NZ

 0064 4 463 6272

 
 From: freeipa-users-boun...@redhat.com
 [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal
 [d...@redhat.com]
 Sent: Tuesday, 20 March 2012 9:19 a.m.
 To: freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] Extending IPA schema for Federation
 services.

 On 03/19/2012 03:58 PM, Steven Jones wrote:
 Hi,

 Im starting from scratch here so bear with me..ie I dont know a
 lot of thiswhich should be obvious

 Extending Easy? oh because it doesnt strike me as easy..

 :/

 Initially I am about to build our production IPA servers.  These
 attributes are a requirement of the Federation system New Zealand
 wants to use and is probably the same for Australia. So I think the
 schema has to be done/extended for IPA to be viable in tertiary
 institutions in NZ, without it not many if anyone will use IPA they
 will stay with openldap.  So each person should have these I
 think.they may not be used initially but once extended initially
 then I dont have to extend the schema later.

 What connects to these is an apache/tomcat front end. There are two
 aspects/functions to this, the IdP and the SdP.  The Idp allows
 remote tertiary organisations to query us and say our user is we
 legitthey then use their LDAP to provide resources via the SdP. 
 So the Idp provides an identity to remote ppl and the SdP provides
 access to a resource at our end. later I expect we will have to to
 the SdP bit got our high performance cluster and storage...

 It maybe a year or more before we actually use this, but it strikes
 me as sensible that these are done on initial build.I will put
 ina  RH support case for this.   We will probably also pull the
 actual fields/contents out of AD.not sure yet.


 The question is simple: how you plan to manage these attributes in IPA?
 Do you expect them to be a part of the UI/CLI or they should be hidden
 there and be managed via ldapmodify and other data sync tools?

 This make the whole difference especially the UI part. Depending upon
 these expectations the scope would be different.


 regards

 Steven Jones

 Technical Specialist - Linux RHCE

 Victoria University, Wellington, NZ

 0064 4 463 6272

 
 From: Rob Crittenden [rcrit...@redhat.com]
 Sent: Tuesday, 20 March 2012 2:55 a.m.
 To: Steven Jones
 Cc: freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] Extending IPA schema for Federation
 services.

 Steven Jones wrote:
 Hi,


 Is it possible to expand IPA's schema to do this?
 Adding the schema is easy, doing something with it is where things get
 interesting. What do you want to do with these
 attributes/objectclasses?

 rob

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users


 -- 
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager IPA project,
 Red Hat Inc.


 ---
 Looking to carve out IT costs?
 www.redhat.com

Re: [Freeipa-users] Extending IPA schema for Federation services.

2012-03-18 Thread Dmitri Pal
On 03/18/2012 08:55 PM, Steven Jones wrote:
 Hi,


 Is it possible to expand IPA's schema to do this?



Yes.
Steps:
1) Convert schema to the correct schema format
2) Add it to the DS schema by placing the file onto the right place. Now
you have it available for use by IPA via LDAP tools.
3) Use ipa config to tell IPA to add this schema to user object.  
4) You can use --setaddr and --addaddr switches to populate these
attributes via CLI
I do not think it is exposed in UI.

To make it available via UI and CLI natively the plugins should be
developed following the extensibility guide.


 ===

 Your Identity Management System (IdMS) will very likely have most of the 
 attributes asked for by the federation - or will have enough information to 
 synthesize the specific attribute values on the fly inside the IdP. But for 
 some attributes, the IdMS might not have enough information. The following 
 information should be considered for adding into your IdMS:

   *   eduPersonEntitlement: The eduPersonEntitlement attribute is a storage 
 container for values representing privileges to access resources within the 
 federation. It is a multi-valued string attribute. The values will have the 
 form of a URI - with specific values that are yet to be defined. The 
 attribute definition details are (source: Attribute Recommendation 2.1 
 (PDF)https://wiki.caudit.edu.au/confluence/download/attachments/784/auEduPerson_attribute_vocabulary_v02+1+0.pdf,
  page 14):

 Origin/ObjectClass:   eduPerson [eduPerson]
 OID:  1.3.6.1.4.1.5923.1.1.1.7
 SAML attribute name:  urn:mace:dir:attribute-def:eduPersonEntitlement
 LDAP syntax:  directoryString [1.3.6.1.4.1.1466.115.121.1.15]
 Number of values: Multiple
 Example values:   eduPersonEntitlement: 
 urn:mace:washington.edu:confocalMicroscope
   eduPersonEntitlement: 
 http://publisher.example.com/contract/GL123

   *   auEduPersonSharedToken: The auEduPersonSharedToken uniquely identifies 
 users when accessing certain resources - particularly within the 
 computational grid and data grid. The values should be opaque, 
 non-reassignable and persistent - and transferrable when a user moves between 
 institutions. Even though the values are typically created as hash-values on 
 first use, they MUST be stored and each institution must be ready to accept 
 values users already have when coming from another institution. The attribute 
 can be stored in either the IdMS directly (preferred) or in a database. The 
 attribute definition details are (source: Attribute Recommendation 2.1 
 (PDF)https://wiki.caudit.edu.au/confluence/download/attachments/784/auEduPerson_attribute_vocabulary_v02+1+0.pdf,
  pages 9-10, with OID updated to correct value):

 Origin/ObjectClass:   auEduPerson
 OID:  1.3.6.1.4.1.27856.1.2.5
 SAML attribute name   
 urn:mace:federation.org.au:attribute:auEduPersonSharedToken
 LDAP syntax:  directoryString [1.3.6.1.4.1.27856.1.2.5]
 Number of values: Single
 Example values:   ZsiAvfxa0BXULgcz7QXknbGtfxk

  *   See also the auEduPerson LDAP Schema 
 Definitionhttps://wiki.caudit.edu.au/confluence/display/aafaueduperson/LDAP+Schema+Definitions
  for exact LDAP definition snippets.

   *   eduPersonAssurance: This attribute represents the Levels of 
 Assurancehttps://tuakiri.ac.nz/confluence/display/Tuakiri/Levels+of+Assurance.
  Either add the attribute into the IdMS directly, or start collecting enough 
 information to synthesize the values later in a scripted attribute definition 
 (like done for Affiliation below).  The attribute definition details are 
 (source: Attribute Recommendation 2.1 
 (PDF)https://wiki.caudit.edu.au/confluence/download/attachments/784/auEduPerson_attribute_vocabulary_v02+1+0.pdf,
  page 13):

 Origin/ObjectClass:   eduPerson
 OID:  1.3.6.1.4.1.5923.1.1.1.11
 SAML attribute name:  urn:oid:1.3.6.1.4.1.5923.1.1.1.11
 LDAP syntax:  directoryString [1.3.6.1.4.1.1466.115.121.1.15]
 Number of values: multiple
 Example values:   See AAF IdentityLoA Vocabulary

 =



 regards

 Steven Jones

 Technical Specialist - Linux RHCE

 Victoria University, Wellington, NZ

 0064 4 463 6272


 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users