Grouper Users - Open Discussion List

[Chris Hyzer <>]

Its on my personal roadmap to make a contrib which handles this.  Not sure when it will happen.  How we handle this at penn is as you describe:

 

1. Make a table (really all you need is principal name…):

 

SET DEFINE OFF;

CREATE TABLE service_principals

(

  PRINCIPAL_NAME     VARCHAR2(512 CHAR),

  ID                 INTEGER,

  LAST_UPDATED       TIMESTAMP(6),

  REASON             VARCHAR2(4000 BYTE),

  PENNKEY_WHO_ADDED  CHAR(20 CHAR),

  PENNID_WHO_ADDED   VARCHAR2(20 BYTE)

);

 

COMMENT ON COLUMN SERVICE_PRINCIPALS.REASON IS 'reason for adding this principal';

 

COMMENT ON COLUMN SERVICE_PRINCIPALS.PENNKEY_WHO_ADDED IS 'pennkey who added the record';

 

COMMENT ON COLUMN SERVICE_PRINCIPALS.PENNID_WHO_ADDED IS 'pennid who added the record';

 

 

CREATE UNIQUE INDEX SERVICE_PRINCIPALS_PK ON SERVICE_PRINCIPALS

(PRINCIPAL_NAME)

LOGGING

NOPARALLEL;

 

ALTER TABLE SERVICE_PRINCIPALS ADD (

  CONSTRAINT SERVICE_PRINCIPALS_PK

 PRIMARY KEY

 (PRINCIPAL_NAME));

SET DEFINE OFF;

 

 

2. Make a source (note, I prefer the JDBC2 sources, but in this case it doesn’t add much value):

 

<source adapterClass="edu.internet2.middleware.subject.provider.JDBCSourceAdapter">

    <id>servPrinc</id>

    <name>Kerberos service principals</name>

     <type>application</type>

     <init-param>

       <param-name>jdbcConnectionProvider</param-name>

       <param-value>edu.internet2.middleware.grouper.subj.GrouperJdbcConnectionProvider</param-value>

     </init-param>

    

      <init-param>

       <param-name>SubjectID_AttributeType</param-name>

       <param-value>loginid</param-value>

     </init-param>

     <init-param>

       <param-name>Name_AttributeType</param-name>

       <param-value>name</param-value>

     </init-param>

     <init-param>

       <param-name>Description_AttributeType</param-name>

       <param-value>description</param-value>

     </init-param>

 

     <search>

         <searchType>searchSubject</searchType>

      <param>

          <param-name>numParameters</param-name>

          <param-value>1</param-value>

        </param>

         <param>

             <param-name>sql</param-name>

             <param-value>

select

   principal_name as name,

   principal_name as loginid,

   principal_name as description

from

   service_principals

where

   principal_name = ?

             </param-value>

         </param>

     </search>

     <search>

         <searchType>searchSubjectByIdentifier</searchType>

      <param>

          <param-name>numParameters</param-name>

          <param-value>1</param-value>

        </param>

         <param>

             <param-name>sql</param-name>

             <param-value>

select

   principal_name as name,

   principal_name as loginid,

   principal_name as description

from

   service_principals

where

   principal_name = ?

 

             </param-value>

         </param>

     </search>

     <search>

        <searchType>search</searchType>

     <param>

          <param-name>numParameters</param-name>

          <param-value>1</param-value>

        </param>

         <param>

             <param-name>sql</param-name>

             <param-value>

select

   principal_name as name,

   principal_name as loginid,

   principal_name as description

from

   service_principals

where

   (lower(principal_name) like concat('%',concat(?,'%')))

             </param-value>

         </param>

     </search>

   </source>

 

3. We made a simple web application which does a few things:

 

a.  Adds a Kerberos principal into this table

b.  Adds the principal to our group which subjects must be in to access our LDAP

c.  (optional) Adds the principal to our group which subjects must be in to access our WS

 

Note: this intake application is also something we are working on as a contrib (no time soon though, but will have workflow provisioning for groups and permissions).

 

Thanks,

Chris

 

 

> -----Original Message-----

> From: Scott Koranda [mailto:]

> Sent: Friday, October 30, 2009 5:28 PM

> To:

> Subject: [grouper-users] authentication/authorization GrouperSystem for

> Grouper web services

>

> Hi,

>

> (Sorry, longish note trying to explain the context...)

>

> Currently we have a "web portal", coded in PHP, that drives

> Grouper web services. The Grouper web services are served via

> SSL/HTTPS and the portal PHP code authenticates as user

> 'GrouperSystem' because of this entry in tomcat-users.xml:

>

> <tomcat-users>

>     <role rolename="grouper_user"/>

>     <user username="GrouperSystem" password="XXXXXXX" roles =

> "grouper_user"/>

> </tomcat-users>

>

> We want the portal to be authenticated as 'GrouperSystem' so

> that it has the privileges to do everything it needs to

> do--fine grained authorization is handled by the portal code

> doing lookups into Grouper and using an 'act as' argument when

> necessary.

>

> Now I want to change that architecture a bit.

>

> I want to protect all of Grouper web services (served via

> Tomcat5 with Apache httpd in front) with some standard Apache

> httpd authentication--right now mod_auth_kerb and eventually

> Shibboleth.

>

> With Chris' help yesterday I got that working with Grouper

> 1.4.x and a custom non-rampart authentication class. So I can

> for example drive a Grouper REST interface after

> authenticating with my Kerberos credentials

> ''. This allows individual users to

> drive the Grouper web services using their individual

> credentials, and that should allow us to build some custom UIs

> with something like AJAX technology. Looking forward to

> Grouper 1.5 it sounds like I won't even need a custom

> class--it will just be a configuration option.

>

> But what about that web portal? How can I get the PHP web

> portal to continue to be authenticated as 'GrouperSystem'?

>

> I can surely issue a Kerberos principal for the portal and

> have it authenticate using that, but it will end up being

> something like '', which is not simply

> 'GrouperSystem'.

>

> Of course I can always add a subject to the wheel group and so

> it will have the same privileges as 'GrouperSystem', but that

> subject needs to be resolved by Grouper.

>

> I suppose I could add '' into our LDAP

> (all of our people subjects are resolved by Grouper in LDAP),

> but that seems messy.

>

> Is there a simple way for me to configure sources.xml so that

> '' or similar is resolved to 'GrouperSystem'? Or

> would I have to do something like stand up an additional JDBC

> source with that one mapping in it?

>

> I appreciate any input anybody has.

>

> Thanks,

>

> Scott