Bug 633503 - Reorganise Security chapter
Summary: Reorganise Security chapter
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: Grid_User_Guide
Version: Development
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
: ---
Assignee: David Ryan
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On: 652506 733205
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-13 20:43 UTC by Lana Brindley
Modified: 2015-02-01 23:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-17 02:57:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Lana Brindley 2010-09-13 20:43:36 UTC
From rrati on BZ #632238. This task held over to 1.4:

>  - Expand overview to relate "access levels" to "authorization" in overview
>  - Order subsections the same as concepts are introduced in overview, and how
> they are referenced, e.g. authentication before authorization because that is
> the order they are introduced and authorization refers to details of
> authentication

LKB

Comment 1 Lana Brindley 2010-09-13 20:50:11 UTC
>   - How do we map the information from the table onto actual configuration? 
> Suggest changing "Access level required" to Context as that's the correct

 <thead>
	<row>
		<entry>
			Activity
		</entry>
		<entry>
			Service
		</entry>
		<entry>
			Security Context
		</entry>

	</row>

</thead>

> security jargon here, and moving the table into an appendix that is referenced
> throughout the chapter.  These security contexts can be used in the more
> restrictive security context (authentication, integrity, etc) as well as the
> Host-Based security (which is the type we ship by default).  This table is
> really meant as a reference to ease the understanding of the type of security
> context needed for a certain task.  It is important we keep the jargon the
> same, as the format we tell users to use in 3.2 is SEC_CONTEXT_FEATURE, and the
> table is providing the type of CONTEXT for given activities.  There needs to be
> better wording to clarify what the table is representing in the overall
> security configuration.
> 

I'll restructure this for 1.4. Added to BZ #633503.

LKB

Comment 2 Lana Brindley 2010-09-13 23:35:28 UTC
>  3.2. Security negotiation
>   - Concept needs introduction in the overview
>   - "Negotiation is performed by the condor_negotiator service" - incorrect as
> negotiation happens between any client and service when a connection is made
>   - Need link between Access Levels and /CONTEXT/ or use common vernacular
> throughout.  I suggest using context.
>   - DEFAULT concept introduced but not explained.  From the condor manual "The
> DEFAULT value for <context> provides a way to set a policy for all access
> levels (READ, WRITE, etc.) that do not have a specific configuration variable
> defined"

Comment 3 Lana Brindley 2010-09-13 23:43:47 UTC
>  3.3. Authentication
>   - Needs overview (see condor manual)

Comment 4 Lana Brindley 2010-09-13 23:48:15 UTC
>  3.4. Authentication methods
>   - Need link between "Windows"" and NTSSAPI
>   - Generally need linkage between type here and from previous section, e.g.
> Filesystem = FS
>   SSL
>    - Needs to expand with an example (example for setting up a Certificate
> Authority for use with SSL provided in earlier BZ, but here it is again:
> http://pages.cs.wisc.edu/~zmiller/ca-howto/)

Comment 5 Alison Young 2011-02-15 02:35:11 UTC
Pushing to 2.1 due to time and resource constraints.


Note You need to log in before you can comment on or make changes to this bug.