does this make sense as an administrative tool in CAS4?

[Scott Battaglia-2]

I'm working on some of the pieces required to support SAML2 in CAS4, including the generation of the appropriate IdP Meta Data automatically etc.

One of the optional components of the IdP meta data is Organizational information.  Does anyone feel like they would actually publish that?  If not we could leave it out of the auto-generated piece and it would mean less admin UI.  Those who want it can manually construct their IdP meta data.

Also, do we want a command line tool for creating the Public/Private Key pairs?  Doing it from some form of administrative screen means we'd most likely have a database requirement for that information.

Thoughts?

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Andrew Feller]

Some javascript/style in this post has been disabled (why?)

Can you elaborate on the purpose and function of the administrative screens?  I was looking at the CAS4 wiki pages ( http://www.ja-sig.org/wiki/display/CAS4UM/ ) and didn’t notice any documentation talking about them.

Are they for A) Viewing state of currently running CAS instance, B) Changing runtime settings of live CAS instance, C) Changing startup settings of CAS instance, D) All of the above?

Thanks,
A-


On 6/26/09 1:36 PM, "Scott Battaglia" <scott.battaglia@...> wrote:

I'm working on some of the pieces required to support SAML2 in CAS4, including the generation of the appropriate IdP Meta Data automatically etc.

One of the optional components of the IdP meta data is Organizational information.  Does anyone feel like they would actually publish that?  If not we could leave it out of the auto-generated piece and it would mean less admin UI.  Those who want it can manually construct their IdP meta data.

Also, do we want a command line tool for creating the Public/Private Key pairs?  Doing it from some form of administrative screen means we'd most likely have a database requirement for that information.

Thoughts?

--
Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: [phone]

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Scott Battaglia-2]

The only thing I'm asking about is whether we need an administrative interface to store the data that's optional for SAML meta data, such as organization and stuff.  If people aren't really going to bother putting in that data then I won't make an interface for it.

I already have a tool to automatically generate the required meta data, it was just if I needed something to allow someone to enter the optional stuff.

On Fri, Jun 26, 2009 at 4:21 PM, Andrew Feller <[hidden email]> wrote:

Can you elaborate on the purpose and function of the administrative screens?  I was looking at the CAS4 wiki pages ( http://www.ja-sig.org/wiki/display/CAS4UM/ ) and didn’t notice any documentation talking about them.

Are they for A) Viewing state of currently running CAS instance, B) Changing runtime settings of live CAS instance, C) Changing startup settings of CAS instance, D) All of the above?

Thanks,
A-

On 6/26/09 1:36 PM, "Scott Battaglia" <scott.battaglia@...> wrote:

I'm working on some of the pieces required to support SAML2 in CAS4, including the generation of the appropriate IdP Meta Data automatically etc.

One of the optional components of the IdP meta data is Organizational information.  Does anyone feel like they would actually publish that?  If not we could leave it out of the auto-generated piece and it would mean less admin UI.  Those who want it can manually construct their IdP meta data.

Also, do we want a command line tool for creating the Public/Private Key pairs?  Doing it from some form of administrative screen means we'd most likely have a database requirement for that information.

Thoughts?

--
Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: [phone]

-- 
You are currently subscribed to [hidden email] as: [hidden email]


To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Marvin Addison]

> One of the optional components of the IdP meta data is Organizational
> information.  Does anyone feel like they would actually publish that?

We don't publish any of that for our Shib/InCommon participation, and
wouldn't likely for CAS either.  From my experience, metadata
administration is a pain, so anything that can be done to facilitate
it would be helpful.  That said, requiring more work for optional
fields sounds fair.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Scott Battaglia-2]

Assuming then that we use a standard convention for the URL endpoints for the various profiles, that leave's the following to be configured:

* Entity ID
* Public/Private Keys (only the public to be published)

Am I missing any?  These look like simple configuration via property/JNDI/whatever with the possible exception that we might want a tool to make it easier to generate and configure appropriate public/private keys.

Thoughts?

On Mon, Jun 29, 2009 at 1:26 PM, Marvin Addison <[hidden email]> wrote:

> One of the optional components of the IdP meta data is Organizational
> information.  Does anyone feel like they would actually publish that?

We don't publish any of that for our Shib/InCommon participation, and
wouldn't likely for CAS either.  From my experience, metadata
administration is a pain, so anything that can be done to facilitate
it would be helpful.  That said, requiring more work for optional
fields sounds fair.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Marvin Addison]

> do we want a command line tool for creating the Public/Private Key
> pairs?

Unless you wanted a pure Java solution to that need, there are already
good tools for that on major platforms; OpenSSL for *nix and the
certificate management MMC console on Windows.  We developed a CLI
tool for an open source Java crypto library we wrote, but that was
more for completeness than anything else.
(http://code.google.com/p/vt-middleware/wiki/vtcrypt#enc_-_Symmetric_Encryption_Operations).

If you wanted to make keypair generation painfully simple, I think the
only way you could top the platform-specific tools would be to provide
a tool in the CAS admin UI.  I would recommend omitting it and adding
it only in response to feature requests for simplified keypair
management.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Marvin Addison]

> Assuming then that we use a standard convention for the URL endpoints
> for the various profiles, that leave's the following to be configured:
> * Entity ID

InCommon just released the following notice about EntityID,
https://spaces.internet2.edu/display/InCCollaborate/IdP+entityID+Shift+to+URLs+--+FAQ,
where they recommended basing it on IDP URL.  In the case of CAS, this
could reasonably be the CAS root URL, e.g.
https://www.example.com/cas, which I would imagine you could derive
from other configuration data.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Scott Battaglia-2]

There actually is code already in CAS4 for generating public/private keys and displaying them for the purposes of SPs that need an easy way to generate the SAML meta data.

We could re-purpose part of that code for IdP meta data.

Cheers,
-Scott

On Mon, Jun 29, 2009 at 1:34 PM, Marvin Addison <[hidden email]> wrote:

> do we want a command line tool for creating the Public/Private Key
> pairs?

Unless you wanted a pure Java solution to that need, there are already
good tools for that on major platforms; OpenSSL for *nix and the
certificate management MMC console on Windows.  We developed a CLI
tool for an open source Java crypto library we wrote, but that was
more for completeness than anything else.
(http://code.google.com/p/vt-middleware/wiki/vtcrypt#enc_-_Symmetric_Encryption_Operations).

If you wanted to make keypair generation painfully simple, I think the
only way you could top the platform-specific tools would be to provide
a tool in the CAS admin UI.  I would recommend omitting it and adding
it only in response to feature requests for simplified keypair
management.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Scott Battaglia-2]

Its actually non-trivial to derive that from anything but runtime data.

The ServletContext does not appear to expose that (even in Java EE5) though the ContextPath is available at the ServletContext level.  Even at run-time, for the request, its probably based on the Host header sent

Do you know of another way?

Cheers,
Scott

On Mon, Jun 29, 2009 at 1:38 PM, Marvin Addison <[hidden email]> wrote:

> Assuming then that we use a standard convention for the URL endpoints
> for the various profiles, that leave's the following to be configured:
> * Entity ID

InCommon just released the following notice about EntityID,
https://spaces.internet2.edu/display/InCCollaborate/IdP+entityID+Shift+to+URLs+--+FAQ,
where they recommended basing it on IDP URL.  In the case of CAS, this
could reasonably be the CAS root URL, e.g.
https://www.example.com/cas, which I would imagine you could derive
from other configuration data.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Andrew Feller]

Some javascript/style in this post has been disabled (why?)

I understand the scope of your question, but I was trying to go on a tangent about administrative screens and the need for a database as a whole.  As there is no wiki documentation about what types of administration screens are being considered for CAS4, I thought it would be a good time to bring it up and explore them as that conversation might answer how to deal with your specific question.

I would be interested in hearing more about the topic if you have time to digress on the subject. =)

On 6/27/09 9:32 PM, "Scott Battaglia" <scott.battaglia@...> wrote:

The only thing I'm asking about is whether we need an administrative interface to store the data that's optional for SAML meta data, such as organization and stuff.  If people aren't really going to bother putting in that data then I won't make an interface for it.

I already have a tool to automatically generate the required meta data, it was just if I needed something to allow someone to enter the optional stuff.


On Fri, Jun 26, 2009 at 4:21 PM, Andrew Feller <afelle1@...> wrote:

Can you elaborate on the purpose and function of the administrative screens?  I was looking at the CAS4 wiki pages ( http://www.ja-sig.org/wiki/display/CAS4UM/ ) and didn’t notice any documentation talking about them.

Are they for A) Viewing state of currently running CAS instance, B) Changing runtime settings of live CAS instance, C) Changing startup settings of CAS instance, D) All of the above?

Thanks,
A-



On 6/26/09 1:36 PM, "Scott Battaglia" <scott.battaglia@... <http://scott.battaglia@...> > wrote:

I'm working on some of the pieces required to support SAML2 in CAS4, including the generation of the appropriate IdP Meta Data automatically etc.

One of the optional components of the IdP meta data is Organizational information.  Does anyone feel like they would actually publish that?  If not we could leave it out of the auto-generated piece and it would mean less admin UI.  Those who want it can manually construct their IdP meta data.

Also, do we want a command line tool for creating the Public/Private Key pairs?  Doing it from some form of administrative screen means we'd most likely have a database requirement for that information.

Thoughts?

--
Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: [phone]

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Scott Battaglia-2]

On Mon, Jun 29, 2009 at 3:33 PM, Andrew Feller <[hidden email]> wrote:

I understand the scope of your question, but I was trying to go on a tangent about administrative screens and the need for a database as a whole.

That's fine, but we should probably make sure to answer the original question first, since I have enough trouble getting responses for the questions I actually ask :-)  As for whether there needs to be a database, it depends on what data we need to make available.  Again, if you look at the context of the original question, there's a set of meta data that is optional for the SAML2 IdP meta data.  If we were autogenerating that meta data, and we care about making it easy to update optional information, then we need to store the source data somewhere (i.e. the Organization or Contact Information) such that the meta data could be reconstructed.
 

 As there is no wiki documentation about what types of administration screens are being considered for CAS4, I thought it would be a good time to bring it up and explore them as that conversation might answer how to deal with your specific question.

Again, my specific question is purely about configuring meta data for SAML2 support, and not about any other administrative screens.  Any other administrative screens are less important because no one's committed to helping out with them.  I'm all for requirements gathering for other administrative functions (which if you look at the list archives, I've tried before).  I need this information, hence the question, because its the piece I'm working on now.  I'll pretend we're doing interative development ;-)

I would be interested in hearing more about the topic if you have time to digress on the subject. =)

I'm all for digressing, I just don't want to lose track of the original question because that's the piece that's currently being written.  Also, not to put you on the spot, but if you're interested in Administrative Screens/Functions, and you've got some free time, the Steering Committee would be more than happy to let you drive the requirements gathering for the administrative screens.  I'd obviously help where I can, but we have actually minimal requirements at Rutgers for administrative functions beyond Services Management. Let me know if you're interested.

Cheers,
Scott
  

On 6/27/09 9:32 PM, "Scott Battaglia" <scott.battaglia@...> wrote:

The only thing I'm asking about is whether we need an administrative interface to store the data that's optional for SAML meta data, such as organization and stuff.  If people aren't really going to bother putting in that data then I won't make an interface for it.

I already have a tool to automatically generate the required meta data, it was just if I needed something to allow someone to enter the optional stuff.


On Fri, Jun 26, 2009 at 4:21 PM, Andrew Feller <afelle1@...> wrote:

Can you elaborate on the purpose and function of the administrative screens?  I was looking at the CAS4 wiki pages ( http://www.ja-sig.org/wiki/display/CAS4UM/ ) and didn’t notice any documentation talking about them.

Are they for A) Viewing state of currently running CAS instance, B) Changing runtime settings of live CAS instance, C) Changing startup settings of CAS instance, D) All of the above?

Thanks,
A-

On 6/26/09 1:36 PM, "Scott Battaglia" <scott.battaglia@... <http://scott.battaglia@...> > wrote:

I'm working on some of the pieces required to support SAML2 in CAS4, including the generation of the appropriate IdP Meta Data automatically etc.

One of the optional components of the IdP meta data is Organizational information.  Does anyone feel like they would actually publish that?  If not we could leave it out of the auto-generated piece and it would mean less admin UI.  Those who want it can manually construct their IdP meta data.

Also, do we want a command line tool for creating the Public/Private Key pairs?  Doing it from some form of administrative screen means we'd most likely have a database requirement for that information.

Thoughts?

--
Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: [phone]

-- 
You are currently subscribed to [hidden email] as: [hidden email]


To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Jason Shao (CampusEAI Consortium)]

Scott,

How do you feel about embedded dbs? We¹ve had pretty good luck using HSQL as
our ³fallback db² for scenarious where we don¹t want to require a JNDI or
other datasource connection or external dependency < especially in the case
of storing preference-type information

We¹ve got a bunch of code that does fallbacks based on: User Configured
Connections -> JNDI at ³known² name -> HSQL.

Admittedly not that many of these bits run on HSQL, but it¹s been great for
testing, and there are a couple edge cases that would have been much more
involved if we didn¹t have that in place.

Jason

On 6/30/09 8:30 AM, "Scott Battaglia" <[hidden email]> wrote:

> On Mon, Jun 29, 2009 at 3:33 PM, Andrew Feller <[hidden email]> wrote:
>> I understand the scope of your question, but I was trying to go on a tangent
>> about administrative screens and the need for a database as a whole.
>
> That's fine, but we should probably make sure to answer the original question
> first, since I have enough trouble getting responses for the questions I
> actually ask :-)  As for whether there needs to be a database, it depends on
> what data we need to make available.  Again, if you look at the context of the
> original question, there's a set of meta data that is optional for the SAML2
> IdP meta data.  If we were autogenerating that meta data, and we care about
> making it easy to update optional information, then we need to store the
> source data somewhere (i.e. the Organization or Contact Information) such that
> the meta data could be reconstructed.
>
>>   As there is no wiki documentation about what types of administration
>> screens are being considered for CAS4, I thought it would be a good time to
>> bring it up and explore them as that conversation might answer how to deal
>> with your specific question.
>
> Again, my specific question is purely about configuring meta data for SAML2
> support, and not about any other administrative screens.  Any other
> administrative screens are less important because no one's committed to
> helping out with them.  I'm all for requirements gathering for other
> administrative functions (which if you look at the list archives, I've tried
> before).  I need this information, hence the question, because its the piece
> I'm working on now.  I'll pretend we're doing interative development ;-)
>
>>
>>
>> I would be interested in hearing more about the topic if you have time to
>> digress on the subject. =)
>
> I'm all for digressing, I just don't want to lose track of the original
> question because that's the piece that's currently being written.  Also, not
> to put you on the spot, but if you're interested in Administrative
> Screens/Functions, and you've got some free time, the Steering Committee would
> be more than happy to let you drive the requirements gathering for the
> administrative screens.  I'd obviously help where I can, but we have actually
> minimal requirements at Rutgers for administrative functions beyond Services
> Management. Let me know if you're interested.
>
> Cheers,
> Scott
>
>>
>>
>> On 6/27/09 9:32 PM, "Scott Battaglia" <[hidden email]
>> <http://scott.battaglia@...> > wrote:
>>
>>> The only thing I'm asking about is whether we need an administrative
>>> interface to store the data that's optional for SAML meta data, such as
>>> organization and stuff.  If people aren't really going to bother putting in
>>> that data then I won't make an interface for it.
>>>
>>> I already have a tool to automatically generate the required meta data, it
>>> was just if I needed something to allow someone to enter the optional stuff.
>>>
>>>
>>> On Fri, Jun 26, 2009 at 4:21 PM, Andrew Feller <[hidden email]
>>> <http://afelle1@...> > wrote:
>>>> Can you elaborate on the purpose and function of the administrative
>>>> screens?  I was looking at the CAS4 wiki pages (
>>>> http://www.ja-sig.org/wiki/display/CAS4UM/ ) and didn¹t notice any
>>>> documentation talking about them.
>>>>
>>>> Are they for A) Viewing state of currently running CAS instance, B)
>>>> Changing runtime settings of live CAS instance, C) Changing startup
>>>> settings of CAS instance, D) All of the above?
>>>>
>>>> Thanks,
>>>> A-
>>>>
>>>>
>>>>
>>>> On 6/26/09 1:36 PM, "Scott Battaglia" <[hidden email]
>>>> <http://scott.battaglia@...>  <http://scott.battaglia@...> >
>>>> wrote:
>>>>
>>>>> I'm working on some of the pieces required to support SAML2 in CAS4,
>>>>> including the generation of the appropriate IdP Meta Data automatically
>>>>> etc.
>>>>>
>>>>> One of the optional components of the IdP meta data is Organizational
>>>>> information.  Does anyone feel like they would actually publish that?  If
>>>>> not we could leave it out of the auto-generated piece and it would mean
>>>>> less admin UI.  Those who want it can manually construct their IdP meta
>>>>> data.
>>>>>
>>>>> Also, do we want a command line tool for creating the Public/Private Key
>>>>> pairs?  Doing it from some form of administrative screen means we'd most
>>>>> likely have a database requirement for that information.
>>>>>
>>>>> Thoughts?

--
Jason Shao
Director of Product Development
CampusEAI Consortium
1940 East 6th Street, 11th Floor
Cleveland, OH 44114
Tel: [phone]x249
Fax: [phone]


Your input is important to improve upon our continuous efforts to service you better. Please e-mail my manager at [hidden email] with any feedback.

CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and confidential; intended for only the recipient(s) named above and may contain information that is privileged. You should not retain, copy or use this e-mail or any attachments for any purpose, or disclose all or any part of the contents to any person. Any views or opinions expressed in this e-mail are those of the author and do not represent those of CampusEAI Consortium or the Open Student Television Network. If you have received this e-mail in error, or are not the named recipient(s), you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited by the sender and to do so might constitute a violation of the Electronic Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender and delete this e-mail and any attachments from your computer. Warning: Although precautions have been taken to make sure no viruses are present in this e-mail, the companies cannot accept responsibility for any loss or damage that arise from the use of this e-mail or attachments.

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Marvin Addison]

> How do you feel about embedded dbs? We¹ve had pretty good luck using  
> HSQL as
> our ³fallback db² for scenarious where we don¹t want to require a  
> JNDI or
> other datasource connection or external dependency < especially in  
> the case
> of storing preference-type information

As you mentioned HSQL is great for testing, but it is totally  
unsuitable for use in any case where durable data storage is  
required.  Other embedded databases may have better shutdown  
semantics, but if a Java process containing HSQL terminates abruptly  
(e.g. SIGKILL), there is absolutely no way to guarantee that it  
flushes in-memory data to disk.  So HSQL could be used for the "demo"  
case where CAS works out of the box, but it wouldn't remove the need  
for a "real" database for production deployments.

M
--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Raymond D Walker]

Howdy folks,

In researching for our upgrade to CAS 3.x I'm looking to put some backwards
compatibility into our implementation for some custom modifications made in
our CAS2.x implementation.

For a few particular applications, we added an optional parameter into
serviceValidate and proxyValidate that allowed for the return of the
expiration time of the cas credentials. This modification was somewhat
involved and required a large amount of class modification.

For our CAS3.x rollout, we'd like to stay away from major modifications such
as this, but I wanted to bounce the idea off the list to see if there was
any straightforward methods to do something similar. Peeking into the code,
and being only mildly familiar with Spring, I'm not seeing this as of yet.
It's looking like a large amount of class modification. Not implementing
this mod will push back our upgrade till some other systems are dealt with,
which is not the issue, but I would like to see what the dev list has to say
about this type of modification, or if anyone has implemented something
similar.

Thanks much,
--
Raymond Walker
Software Systems Engineer Sr.
ITS Northern Arizona University
[hidden email]
Phone [phone]



--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Scott Battaglia-2]

Can you clarify what you mean by "CAS credentials" because in your title you talk about returning ticket expiration time (TGT, ST, PT, etc?)

On Mon, Jul 6, 2009 at 11:20 AM, Raymond D Walker <[hidden email]> wrote:

Howdy folks,

In researching for our upgrade to CAS 3.x I'm looking to put some backwards
compatibility into our implementation for some custom modifications made in
our CAS2.x implementation.

For a few particular applications, we added an optional parameter into
serviceValidate and proxyValidate that allowed for the return of the
expiration time of the cas credentials. This modification was somewhat
involved and required a large amount of class modification.

For our CAS3.x rollout, we'd like to stay away from major modifications such
as this, but I wanted to bounce the idea off the list to see if there was
any straightforward methods to do something similar. Peeking into the code,
and being only mildly familiar with Spring, I'm not seeing this as of yet.
It's looking like a large amount of class modification. Not implementing
this mod will push back our upgrade till some other systems are dealt with,
which is not the issue, but I would like to see what the dev list has to say
about this type of modification, or if anyone has implemented something
similar.

Thanks much,
--
Raymond Walker
Software Systems Engineer Sr.
ITS Northern Arizona University
[hidden email]
Phone [phone]



--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Raymond D Walker]

Scott,

Apologies, I was unclear with this. Essentially our modification found the
expiration of the beginning of the ticket chain.


On 7/6/09 8:26 AM, "Scott Battaglia" <[hidden email]> wrote:

> Can you clarify what you mean by "CAS credentials" because in your title you
> talk about returning ticket expiration time (TGT, ST, PT, etc?)
>
>
> On Mon, Jul 6, 2009 at 11:20 AM, Raymond D Walker <[hidden email]> wrote:
>> Howdy folks,
>>
>> In researching for our upgrade to CAS 3.x I'm looking to put some backwards
>> compatibility into our implementation for some custom modifications made in
>> our CAS2.x implementation.
>>
>> For a few particular applications, we added an optional parameter into
>> serviceValidate and proxyValidate that allowed for the return of the
>> expiration time of the cas credentials. This modification was somewhat
>> involved and required a large amount of class modification.
>>
>> For our CAS3.x rollout, we'd like to stay away from major modifications such
>> as this, but I wanted to bounce the idea off the list to see if there was
>> any straightforward methods to do something similar. Peeking into the code,
>> and being only mildly familiar with Spring, I'm not seeing this as of yet.
>> It's looking like a large amount of class modification. Not implementing
>> this mod will push back our upgrade till some other systems are dealt with,
>> which is not the issue, but I would like to see what the dev list has to say
>> about this type of modification, or if anyone has implemented something
>> similar.
>>
>> Thanks much,
>> --
>> Raymond Walker
>> Software Systems Engineer Sr.
>> ITS Northern Arizona University
>> [hidden email]
>> Phone [phone]
>>
>>
>>
>> --
>> You are currently subscribed to [hidden email] as:
>> [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/cas-dev
>>

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Scott Battaglia-2]

Raymond,

To our JSP that generates the CAS response, we expose an Assertion object:
https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/validation/Assertion.java

While it doesn't have the expiration times explicitly, it does have the authentication objects which contain the time when they were created:
https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/authentication/Authentication.java

which could allow you to construct your expiration time.

The only thing you'd modify is the JSP page.

Cheers,
Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Mon, Jul 6, 2009 at 11:35 AM, Raymond D Walker <[hidden email]> wrote:

Scott,

Apologies, I was unclear with this. Essentially our modification found the
expiration of the beginning of the ticket chain.

On 7/6/09 8:26 AM, "Scott Battaglia" <[hidden email]> wrote:

> Can you clarify what you mean by "CAS credentials" because in your title you
> talk about returning ticket expiration time (TGT, ST, PT, etc?)
>
>
> On Mon, Jul 6, 2009 at 11:20 AM, Raymond D Walker <[hidden email]> wrote:
>> Howdy folks,
>>
>> In researching for our upgrade to CAS 3.x I'm looking to put some backwards
>> compatibility into our implementation for some custom modifications made in
>> our CAS2.x implementation.
>>
>> For a few particular applications, we added an optional parameter into
>> serviceValidate and proxyValidate that allowed for the return of the
>> expiration time of the cas credentials. This modification was somewhat
>> involved and required a large amount of class modification.
>>
>> For our CAS3.x rollout, we'd like to stay away from major modifications such
>> as this, but I wanted to bounce the idea off the list to see if there was
>> any straightforward methods to do something similar. Peeking into the code,
>> and being only mildly familiar with Spring, I'm not seeing this as of yet.
>> It's looking like a large amount of class modification. Not implementing
>> this mod will push back our upgrade till some other systems are dealt with,
>> which is not the issue, but I would like to see what the dev list has to say
>> about this type of modification, or if anyone has implemented something
>> similar.
>>
>> Thanks much,
>> --
>> Raymond Walker
>> Software Systems Engineer Sr.
>> ITS Northern Arizona University
>> [hidden email]
>> Phone [phone]
>>
>>
>>
>> --
>> You are currently subscribed to [hidden email] as:
>> [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/cas-dev
>>

--

You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Raymond D Walker]

Scott,

In reviewing this, I do not believe we can get a valid expiration time  
for the user's authentication via the suggested method. I also believe  
the title might now be considered misleading as we're looking for a  
user's credential expiration time, not necessarily a ticket expiration  
time.

In our setup we are using the default ticket expiration policy (2hr).

In modifying the casServiceValidation.jsp to extract the Dates from  
the Authentication list, also have exposed the "root" which contains  
the initial Authentication time for the user. This time seems to never  
change.

For example:

3:00pm
cas/login?service=serviceA

On validation, this gives us an Authentication List with the root  
authentication time of 3:00pm. The idea is to do math on this time  
(user valid till 5pm,) which makes sense.

4:00pm
cas/login?service=serviceB

On validation, this gives us an Authentication List with the root  
authentication time of 3:00pm (with no other nodes.) We would not be  
able to correctly do math on this time, since they're valid till  
6:00pm and are able to login to new and existing services without re-
authenticaiton until 6:00pm.

In reviewing the other ticket expiration policies, I do not see a  
policy which would modify this time. I'm curious if we're just looking  
in the wrong direction to acquire a user's expiration time. Any ideas?

Raymond Walker
Software Systems Engineer Sr.
ITS Northern Arizona University

On Jul 7, 2009, at 7:26 PM, Scott Battaglia wrote:

> Raymond,
>
> To our JSP that generates the CAS response, we expose an Assertion  
> object:
> https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/validation/Assertion.java
>
> While it doesn't have the expiration times explicitly, it does have  
> the authentication objects which contain the time when they were  
> created:
> https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/authentication/Authentication.java
>
> which could allow you to construct your expiration time.
>
> The only thing you'd modify is the JSP page.
>
> Cheers,
> Scott
>
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
>
>
> On Mon, Jul 6, 2009 at 11:35 AM, Raymond D Walker  
> <[hidden email]> wrote:
> Scott,
>
> Apologies, I was unclear with this. Essentially our modification  
> found the
> expiration of the beginning of the ticket chain.
>
>
> On 7/6/09 8:26 AM, "Scott Battaglia" <[hidden email]>  
> wrote:
>
> > Can you clarify what you mean by "CAS credentials" because in your  
> title you
> > talk about returning ticket expiration time (TGT, ST, PT, etc?)
> >
> >
> > On Mon, Jul 6, 2009 at 11:20 AM, Raymond D Walker <[hidden email]
> > wrote:
> >> Howdy folks,
> >>
> >> In researching for our upgrade to CAS 3.x I'm looking to put some  
> backwards
> >> compatibility into our implementation for some custom  
> modifications made in
> >> our CAS2.x implementation.
> >>
> >> For a few particular applications, we added an optional parameter  
> into
> >> serviceValidate and proxyValidate that allowed for the return of  
> the
> >> expiration time of the cas credentials. This modification was  
> somewhat
> >> involved and required a large amount of class modification.
> >>
> >> For our CAS3.x rollout, we'd like to stay away from major  
> modifications such
> >> as this, but I wanted to bounce the idea off the list to see if  
> there was
> >> any straightforward methods to do something similar. Peeking into  
> the code,
> >> and being only mildly familiar with Spring, I'm not seeing this  
> as of yet.
> >> It's looking like a large amount of class modification. Not  
> implementing
> >> this mod will push back our upgrade till some other systems are  
> dealt with,
> >> which is not the issue, but I would like to see what the dev list  
> has to say
> >> about this type of modification, or if anyone has implemented  
> something
> >> similar.
> >>
> >> Thanks much,
> >> --
> >> Raymond Walker
> >> Software Systems Engineer Sr.
> >> ITS Northern Arizona University
> >> [hidden email]
> >> Phone [phone]
> >>
> >>
> >>
> >> --
> >> You are currently subscribed to [hidden email] as:
> >> [hidden email]
> >> To unsubscribe, change settings or access archives, see
> >> http://www.ja-sig.org/wiki/display/JSG/cas-dev
> >>
>
>
> --
> You are currently subscribed to [hidden email] as: [hidden email]
> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
>
>
> --
> You are currently subscribed to [hidden email] as: [hidden email]
> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Scott Battaglia-2]

Wouldn't you just be able to do "new Date()" in the JSP page to get the current time the ticket was validated (which is probably within 10 seconds of when it was issued) and then add 2 hours to that?

On Tue, Nov 10, 2009 at 1:38 PM, Raymond D Walker <[hidden email]> wrote:

Scott,

In reviewing this, I do not believe we can get a valid expiration time
for the user's authentication via the suggested method. I also believe
the title might now be considered misleading as we're looking for a
user's credential expiration time, not necessarily a ticket expiration
time.

In our setup we are using the default ticket expiration policy (2hr).

In modifying the casServiceValidation.jsp to extract the Dates from
the Authentication list, also have exposed the "root" which contains
the initial Authentication time for the user. This time seems to never
change.

For example:

3:00pm
cas/login?service=serviceA

On validation, this gives us an Authentication List with the root
authentication time of 3:00pm. The idea is to do math on this time
(user valid till 5pm,) which makes sense.

4:00pm
cas/login?service=serviceB

On validation, this gives us an Authentication List with the root
authentication time of 3:00pm (with no other nodes.) We would not be
able to correctly do math on this time, since they're valid till
6:00pm and are able to login to new and existing services without re-
authenticaiton until 6:00pm.

In reviewing the other ticket expiration policies, I do not see a
policy which would modify this time. I'm curious if we're just looking
in the wrong direction to acquire a user's expiration time. Any ideas?

Raymond Walker
Software Systems Engineer Sr.
ITS Northern Arizona University

On Jul 7, 2009, at 7:26 PM, Scott Battaglia wrote:

> Raymond,
>
> To our JSP that generates the CAS response, we expose an Assertion
> object:
> https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/validation/Assertion.java
>
> While it doesn't have the expiration times explicitly, it does have
> the authentication objects which contain the time when they were
> created:
> https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/authentication/Authentication.java
>
> which could allow you to construct your expiration time.
>
> The only thing you'd modify is the JSP page.
>
> Cheers,
> Scott
>
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
>
>
> On Mon, Jul 6, 2009 at 11:35 AM, Raymond D Walker
> <[hidden email]> wrote:
> Scott,
>
> Apologies, I was unclear with this. Essentially our modification
> found the
> expiration of the beginning of the ticket chain.
>
>
> On 7/6/09 8:26 AM, "Scott Battaglia" <[hidden email]>
> wrote:
>
> > Can you clarify what you mean by "CAS credentials" because in your
> title you
> > talk about returning ticket expiration time (TGT, ST, PT, etc?)
> >
> >
> > On Mon, Jul 6, 2009 at 11:20 AM, Raymond D Walker <[hidden email]
> > wrote:
> >> Howdy folks,
> >>
> >> In researching for our upgrade to CAS 3.x I'm looking to put some
> backwards
> >> compatibility into our implementation for some custom
> modifications made in
> >> our CAS2.x implementation.
> >>
> >> For a few particular applications, we added an optional parameter
> into
> >> serviceValidate and proxyValidate that allowed for the return of
> the
> >> expiration time of the cas credentials. This modification was
> somewhat
> >> involved and required a large amount of class modification.
> >>
> >> For our CAS3.x rollout, we'd like to stay away from major
> modifications such
> >> as this, but I wanted to bounce the idea off the list to see if
> there was
> >> any straightforward methods to do something similar. Peeking into
> the code,
> >> and being only mildly familiar with Spring, I'm not seeing this
> as of yet.
> >> It's looking like a large amount of class modification. Not
> implementing
> >> this mod will push back our upgrade till some other systems are
> dealt with,
> >> which is not the issue, but I would like to see what the dev list
> has to say
> >> about this type of modification, or if anyone has implemented
> something
> >> similar.
> >>
> >> Thanks much,
> >> --
> >> Raymond Walker
> >> Software Systems Engineer Sr.
> >> ITS Northern Arizona University
> >> [hidden email]
> >> Phone [phone]
> >>
> >>
> >>
> >> --
> >> You are currently subscribed to [hidden email] as:
> >> [hidden email]
> >> To unsubscribe, change settings or access archives, see
> >> http://www.ja-sig.org/wiki/display/JSG/cas-dev
> >>
>
>
> --
> You are currently subscribed to [hidden email] as: [hidden email]
> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
>
>

> --
> You are currently subscribed to [hidden email] as: [hidden email]

> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev


--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Raymond D Walker]

Scott,

This makes sense and is valid for determining the end of life of a service ticket. What I'm noticing that I've failed to mention, is that when also dealing with proxies, the process of acquiring a user's authentication expiration time becomes a bit more convoluted. The reason for this is to determine how long a proxy would be able to successfully grant tickets for it's applications.

Modifying my previous example, when we login & validate serviceA, then move on to proxy serviceZ, the TGT retrieved for proxy is at first good until 2hrs from serviceA's validation (approxmately.)

But if we then validate serviceB (and/or other services) one hour later, this effectively extends the time that the user is authenticated one hour past the end of service A's validation.

If I understand correctly, this would effectively extend the usefulness of serviceZ's TGT by one hour. With this in mind, we also know that serviceA & serviceB have no interaction, therefore when serviceZ proxyValidates, there would not be a proper way to obtain a correct time of how long the user would be authenticated for.

(Another potential scenario is if the root TGT's expiration time was less than that of the proxy's TGT. I'm not sure if that is even possible?)

I see that the under .isExpired within AbstractTicket.java the TGT chain is followed to it's root. The root TGT's last used time is updated when /cas/login is called for a service. I believe that this is the time we'd like to acquire, which could be done in a method similar in fashion to how .isExpired tunnels down the TGT chain.

We're looking into the addition of an optional parameter to retrieve this time, at one of two points, either in the cas/proxy or cas/proxyValidate

My question is, is there another preferred method or point of entry to do something like this?

Raymond Walker
Software Systems Engineer Sr.
ITS Northern Arizona University
[hidden email]
Phone [phone]

On Nov 12, 2009, at 9:53 PM, Scott Battaglia wrote:

> Wouldn't you just be able to do "new Date()" in the JSP page to get the current time the ticket was validated (which is probably within 10 seconds of when it was issued) and then add 2 hours to that?
>
>
> On Tue, Nov 10, 2009 at 1:38 PM, Raymond D Walker <[hidden email]> wrote:
> Scott,
>
> In reviewing this, I do not believe we can get a valid expiration time
> for the user's authentication via the suggested method. I also believe
> the title might now be considered misleading as we're looking for a
> user's credential expiration time, not necessarily a ticket expiration
> time.
>
> In our setup we are using the default ticket expiration policy (2hr).
>
> In modifying the casServiceValidation.jsp to extract the Dates from
> the Authentication list, also have exposed the "root" which contains
> the initial Authentication time for the user. This time seems to never
> change.
>
> For example:
>
> 3:00pm
> cas/login?service=serviceA
>
> On validation, this gives us an Authentication List with the root
> authentication time of 3:00pm. The idea is to do math on this time
> (user valid till 5pm,) which makes sense.
>
> 4:00pm
> cas/login?service=serviceB
>
> On validation, this gives us an Authentication List with the root
> authentication time of 3:00pm (with no other nodes.) We would not be
> able to correctly do math on this time, since they're valid till
> 6:00pm and are able to login to new and existing services without re-
> authenticaiton until 6:00pm.
>
> In reviewing the other ticket expiration policies, I do not see a
> policy which would modify this time. I'm curious if we're just looking
> in the wrong direction to acquire a user's expiration time. Any ideas?
>
> Raymond Walker
> Software Systems Engineer Sr.
> ITS Northern Arizona University
>
> On Jul 7, 2009, at 7:26 PM, Scott Battaglia wrote:
>
> > Raymond,
> >
> > To our JSP that generates the CAS response, we expose an Assertion
> > object:
> > https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/validation/Assertion.java
> >
> > While it doesn't have the expiration times explicitly, it does have
> > the authentication objects which contain the time when they were
> > created:
> > https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/authentication/Authentication.java
> >
> > which could allow you to construct your expiration time.
> >
> > The only thing you'd modify is the JSP page.
> >
> > Cheers,
> > Scott
> >
> > -Scott Battaglia
> > PGP Public Key Id: 0x383733AA
> > LinkedIn: http://www.linkedin.com/in/scottbattaglia
> >
> >
> > On Mon, Jul 6, 2009 at 11:35 AM, Raymond D Walker
> > <[hidden email]> wrote:
> > Scott,
> >
> > Apologies, I was unclear with this. Essentially our modification
> > found the
> > expiration of the beginning of the ticket chain.
> >
> >
> > On 7/6/09 8:26 AM, "Scott Battaglia" <[hidden email]>
> > wrote:
> >
> > > Can you clarify what you mean by "CAS credentials" because in your
> > title you
> > > talk about returning ticket expiration time (TGT, ST, PT, etc?)
> > >
> > >
> > > On Mon, Jul 6, 2009 at 11:20 AM, Raymond D Walker <[hidden email]
> > > wrote:
> > >> Howdy folks,
> > >>
> > >> In researching for our upgrade to CAS 3.x I'm looking to put some
> > backwards
> > >> compatibility into our implementation for some custom
> > modifications made in
> > >> our CAS2.x implementation.
> > >>
> > >> For a few particular applications, we added an optional parameter
> > into
> > >> serviceValidate and proxyValidate that allowed for the return of
> > the
> > >> expiration time of the cas credentials. This modification was
> > somewhat
> > >> involved and required a large amount of class modification.
> > >>
> > >> For our CAS3.x rollout, we'd like to stay away from major
> > modifications such
> > >> as this, but I wanted to bounce the idea off the list to see if
> > there was
> > >> any straightforward methods to do something similar. Peeking into
> > the code,
> > >> and being only mildly familiar with Spring, I'm not seeing this
> > as of yet.
> > >> It's looking like a large amount of class modification. Not
> > implementing
> > >> this mod will push back our upgrade till some other systems are
> > dealt with,
> > >> which is not the issue, but I would like to see what the dev list
> > has to say
> > >> about this type of modification, or if anyone has implemented
> > something
> > >> similar.
> > >>
> > >> Thanks much,
> > >> --
> > >> Raymond Walker
> > >> Software Systems Engineer Sr.
> > >> ITS Northern Arizona University
> > >> [hidden email]
> > >> Phone [phone]
> > >>
> > >>
> > >>
> > >> --
> > >> You are currently subscribed to [hidden email] as:
> > >> [hidden email]
> > >> To unsubscribe, change settings or access archives, see
> > >> http://www.ja-sig.org/wiki/display/JSG/cas-dev
> > >>
> >
> >
> > --
> > You are currently subscribed to [hidden email] as: [hidden email]
> > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
> >
> >
> > --
> > You are currently subscribed to [hidden email] as: [hidden email]
> > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
>
>
> --
> You are currently subscribed to [hidden email] as: [hidden email]
> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
>
>
> --
> You are currently subscribed to [hidden email] as: [hidden email]
> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev